On 04/06/2007 01:24 PM, Robert P. J. Day wrote:
so selecting voluntary preemption simply defines possible preemption
whenever you invoke "might_sleep()" or "might_sleep_if()", that's
all. regular (forced) preemption is, of course, still in effect.
No, the important thing to notice is that due to it being a choice
kbuild-wise, having CONFIG_VOLUNTARY_PREEMPT means you don't have
CONFIG_PREEMPT.
"Voluntary Preemption" deserves a price for being one of the most badly
misnamed things ever. "Voluntary Preemption" is an oxymoron; if you are
giving up control voluntary, you are not being preempted. "Voluntary
Preemption" means "No Preemption".
What the config option does is use (abuse, some might say) the
might_sleep debug checks by noting that in fact all of the places where
code said that it might sleep were useable as points to _cause_ it to
sleep -- it was saying it was ready to anyway. There's nothing
preemptive about that though.
Mind you; the above might sound like I don't like VOLUNTARY_PREEMPT but
while I do in fact use a "proper preemptive kernel" CONFIG_PREEMPT does
make for an at least conceptually harder model of the flow of control
inside the kernel, so if the cooperative tasking that these explicit
scheduling points of "CONFIG_VOLUNTRAY_PREEMPT" enables works well,
fine. The name's the worst thing about it...
Let's call it The Fully O(1) Preemptible Low-Latency Choice Enabler!
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
