Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> wrote:

> Minor point:  this:
> 
> 	cond_resched();
> 	function_which_might_sleep();
> 
> is less efficient than
> 
> 	function_which_might_sleep();
> 	cond_resched();
> 
> because if function_which_might_sleep() _does_ sleep, need_resched()
> will likely be false when we hit cond_resched(), thus saving a context
> switch.  Unfortunately, might_sleep() calls tend to go at the entry to
> functions, whereas cond_resched() calls should be neat the exit point,
> or inside loop bodies.

agreed, but the argument goes both ways. Whether entry or exit
scheduling is better very much depends on the function.

E.g. for user copy type of stuff we often want to do the reschedule
_first_, to not pollute the cache with hot (dirty) cachelines that
likely get thrown away - and which have to be brought back again later
on.

For IO type of functions that will sleep we most likely want to preempt
at the exit of the function.

but we'd like to profile the typical preemption points (hence the
profile=sched profiling change) to determine which are the hottest
functions. For those handful of functions we can do __might_sleep() at
the front of the function and a cond_resched() at the back. For all the
other 200 might_sleep() points it doesnt matter much.

i've also added the nr_preempt counter so that we can see the proportion
of forced preemption vs. intentional reschedules for various workloads.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/