Messages in this thread | | | Date | Sun, 11 Jul 2004 11:32:09 +0200 | From | Ingo Molnar <> | Subject | Re: [announce] [patch] Voluntary Kernel Preemption Patch |
| |
* Andrew Morton <akpm@osdl.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |