lkml.org 
[lkml]   [2004]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch] sched: fix scheduling latencies for !PREEMPT kernels
    From
    Date
    On Maw, 2004-09-14 at 20:21, William Lee Irwin III wrote:
    > The "safely call schedule() while holding it" needs quite a bit of
    > qualification; it's implicitly dropped during voluntary context
    > switches and reacquired when rescheduled, but it's not valid to force
    > such a task into an involuntary context switch and calling schedule()
    > implies dropping the lock, so it has to be done at the proper times.
    > This is a complex semantic that likely trips up numerous callers (as
    > well as attempts to explain it, though surely you know these things,
    > and merely wanted a shorter line for the bullet point).

    The problem is people think of the BKL as a lock. It isn't a lock it has
    never been a lock and it's all DaveM's fault 8) for naming it that when
    he moved my asm entry point stuff into C.

    The BKL turns on old style unix non-pre-emptive sematics between all
    code that is within lock_kernel sections, that is it. That also makes it
    hard to clean up because lock_kernel is delimiting code properties (its
    essentially almost a function attribute) and spin_lock/down/up and
    friends are real locks and lock data.

    I've seen very few cases where there is a magic transform from one to
    the other because of this. So if you want to kill the BKL add proper
    locking to data structures covered by BKL users until the lock_kernel
    simply does nothing.

    > or sweeps others care to devolve to me, so I'll largely be using
    > whatever tactic whoever cares to drive all this (probably Alan) prefers.

    Fix the data structure locking starting at the lowest level is how I've
    always tackled these messes. When the low level locking is right the
    rest just works (usually 8)).

    "Lock data not code"

    Alan

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:2.589 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site