[lkml]   [2001]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] 2.4.0-prerelease: preemptive kernel.
    Daniel Phillips wrote:

    > The key idea here is to disable preemption on spin lock and reenable on
    > spin unlock. That's a practical idea, highly compatible with the
    > current way of doing things. Its a fairly heavy hit on spinlock
    > performance, but maybe the overall performance hit is small. Benchmarks
    > are needed.

    I'm not sure the hit on spinlock is this heavy (one increment for lock
    and one dec + test on unlock), but I completely agree (and volonteer)
    for benchmarking. I'm not convinced a full preemptive kernel is something
    interesting mainly due to the context switch cost (actually mmu contex switch).
    Benchmarking is a good way to get a global overview on this.
    What about only preemptable kernel threads ?

    > A more ambitious way to proceed is to change spinlocks so they can sleep
    > (not in interrupts of course). There would not be any extra overhead
    > for this on spin_lock (because the sleep test is handled off the fast
    > path) but spin_unlock gets a little slower - it has to test and jump on
    > a flag if there are sleepers.

    I may be tired but I believe you're focusing on SMP architecture ?
    This code simply defer the preemption at the end of the spinlock/lock
    section. I don't see how you can easily mix sleeping lock and this


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

     \ /
      Last update: 2005-03-22 12:52    [W:0.026 / U:45.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site