[lkml]   [2002]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: flock(fd, LOCK_UN) taking 500ms+ ?
    On Wed, Oct 02, 2002 at 10:04:52AM -0700, Andrew Morton wrote:
    > sched_yield() sementics changed a lot. It used to mean "take a quick
    > nap", but it now means "go to the back of the runqueue and stay there
    > for absolutely ages". The latter is a closer interpretation of the spec,
    > but it has broken stuff which was tuned to the old behaviour.

    *nod*. This code has been around for many many years ;-)

    > It's not really clear why that yield is in there at all? Unless that
    > code is really, really slow (milliseconds) then probably it should just
    > be deleted.

    Heh, you're so focused on perf tuning, Andrew! It's not a matter of
    locking, it's a matter of semantics. Here's the comment:

    * FL_FLOCK locks never deadlock, an existing lock is always removed before
    * upgrading from shared to exclusive (or vice versa). When this happens
    * any processes blocked by the current lock are woken up and allowed to
    * run before the new lock is applied.
    * Andy Walker (, June 09, 1995

    > If there really is a solid need to hand the CPU over to some now-runnable
    > higher-priority process then a cond_resched() will suffice.

    I think that's the right thing to do. If I understand right, we'll
    check needs_resched at syscall exit, so we don't need to do it for
    unlocks, right?

    Revolutions do not require corporate support.
    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 13:29    [W:0.019 / U:60.616 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site