Hi Adam,
Yes, that's a good question. This cannot really happen within L4Re due to the eager memory allocation of moe, so it was never an issue there.
I thought so too because Genode's core pre-allocates all memory from sigma0 at boot time. There are, however, rare cases where the sigma0 protocol is invoked anyway. For example, for handing out MMIO regions to user-level device drivers (roottask doesn't know about those physical regions at boot time) and handing out boot modules.
Because the use of the sigma0 protocol at runtime is extremely rare, and the chance for the time slice running out while a sigma0 request is processed even more so, and the chance to have a fully saturated system even more more so, this problem triggered only sporadically. Circa once in a month, and only in highly complex/dynamic scenarios. We have observed it the first time more than 6 months ago. It took us until now to come up with a stable test case that pinpoints the problem.
I do not really have an opinion on that right now but I'll try to get one.
To me the problem looks like a school-book example for priority inversion, which just happened to got covered up pretty nicely by Fiasco's time-slice donation optimization. Do you have an alternative way to fix it other than boost the priority of sigma0?
You say that L4Re does not use the sigma0 protocol at runtime. Is there a compelling reason for keeping this little guy called sigma0 lurking around in the system then? If not, getting rid of sigma0 (as done by OKL4 or NOVA, btw) would certainly be the cleanest way to fix our problem. .-)
Norman