Remove "early routine kmsg" context
authorBarret Rhoden <brho@cs.berkeley.edu>
Tue, 24 Jul 2018 17:47:04 +0000 (13:47 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 25 Jul 2018 15:25:46 +0000 (11:25 -0400)
commit9851b19f2ad66ef72e6e5b84962f00950e366567
tree9b276f61b50977b7710475b9aafd90ce5131e653
parentc5f7000db927d48d1d9b70016d2de8f5dab6fca4
Remove "early routine kmsg" context

The purpose of was to detect if an RKM/kthread had blocked since we
launched the message.  If it did, then we could be on another core, and we
didn't want to continue checking routine messages from the *old* core.

This was a little hokey, and the intent was to keep us in the PRKM while()
loop for those messages that didn't block.  However, if we just call
smp_idle() after each KMSG, it is essentially the same code.  Both cases
would do the same thing: clear the kthread's flags, report a quiescent
state, disable IRQs, reread core_id/pcpui, then check for another message.

Just calling smp_idle() adds a function call or two to the loop, but it
removes the early RKM checks and clarifies the code.  I imagine the
performance is negligble either way.

The clarity is worth a lot more.  There was at least one bug with the old
code: when we set the pcpui->cur_kthread's flags, pcpui was stale.  That
means we could have clobbered another core's kthread's flags.  At worst,
that could turn off IS_KTASK and turn on SAVE_ADDR_SPACE.  I'm not sure how
that would break anything specifically.

We had a couple cases of RKMs getting ignored (sitting in the core's queue,
but the core had halted).  I don't see exactly how problems in this area
could have caused that, so we'll see.  So far so good.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
Documentation/kernel_messages.txt
kern/include/trap.h
kern/src/kthread.c
kern/src/smp.c
kern/src/trap.c