[lkml]   [2004]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [announce] [patch] Voluntary Kernel Preemption Patch

    * Andrew Morton <> 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

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.021 / U:6.600 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site