Gernot Heiser

I cannot be sure why the implementation ended up the way it is, but I suspect it goes back to originally notifications sharing most of the code path with IPC...

In practice I doubt it's a serious issue. If you have multiple threads waiting on the same notification, then that seems to only make sense if they are multiple working...

@Indanz: I don't disagree with you at all. The "should not affect" was not meant to refer to the current implementation, but to what I consider the right behaviour.

@kent-mcleod: This is kernel-enforced policy, which we should not have. Locality (and whether it matters) depends on the system architecture, the kernel second-guessing userland is the wrong approach for a...

> But even the 20-year paper claimed that microkernel's can't get away from scheduling policy in the kernel :) I don't think that's what it says. It said that it's...

The present behaviour certainly leads to a DOS attack on non-MCS. Threads A and B both run at prio P: - A runs for 90% of its time slice, then...

Stepping back... We have to accept that pre-MCS scheduling is unprincipled and basically impossible to reason about. Ad-hoc policies (aka hacks) try to work around some of the deficiencies but...

Further to my comments above: I think this can all be done very cleanly. In MCS terminology: - the budget is the right to use the CPU for a certain...

> It would be useful if the cache cold case was also measured, but that would require more cache control than what's practical I’ve got a student lined up to...

> I am benchmarking seL4's IPC and finding a performance gap between sel4bench and my own benchmark (I modified the sel4bench IPC benchmark to measure the IPC for my purpose....