On 24/05/15 14:22, Robert Millan wrote:
Then I noticed kpreempt_disable() was a NO-OP stub, and I thought
implementing it might help. It
turned out not to, but I figured it might be useful to someone else.
It's a nop because rump kernel threads are always non-preemptable and
are explicitly scheduled in their own virtual timespace. If the
threading system that the rump kernel is running on does have
preemptable threads (e.g. pthreads), some instructions in the rump
kernel timespace just take longer to complete. However, no races will
occur as a result, i.e. kpreempt_disable() being a nop is not a bug.
Oh I see, I wasn't aware this sort of magic was underneath. Thanks for
the explanation, I stand corrected.
It's not really magic, but the fundamental feature of rump kernels is
that they run on external threads. It is what makes rump kernels highly
integratable without a performance penalty. It also of course makes
some things a bit different. I always tell people that if understanding
how the rump kernel scheduler works seems difficult, they shouldn't feel
bad, it's not completely obvious if your background is in "regular
scheduling". I got the first incarnation of the scheduler done in 2009,
i.e. it took me over two years to figure out what's required and how to
implement it. I think everyone else can now figure it out faster than
me in less than 10000-or-so hours.
So don't feel bad, we all take wrong turns when exploring, more or less
by the definition of "exploring". I'd rather explain why some patch is
not necessary than risk never seeing good patches because of the fear of
being wrong.
