[lkml]   [2002]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ps performance sucks (was Re: dcache_rcu [performance results])
    On Thu, Nov 07, 2002 at 11:06:13PM +1100, Rusty Russell wrote:
    > Now, according to wli, there's a real problem with starvation by saturating
    > the read side of the tasklist_lock so eg. the write_lock_irq(&tasklist_lock)
    > in exit.c's release_task causes a CPU to spin for ages (forever?) with
    > interrupts off. This needs fixing, be it RCU or making that particular
    > lock give way to writers, or some other effect.

    One way to at least "postpone" having to do things like making a fair
    tasklist_lock is to make readers well-behaved. /proc/ is the worst
    remaining offender left with its quadratic (!) get_pid_list(). After
    "kernel, you're being bad and spinning in near-infinite loops with the
    tasklist_lock readlocked" is (completely?) solved, then we can wait for
    boxen with higher cpu counts to catch fire anyway when the arrival rate
    of readers * hold time of readers > 1, which will happen because arrival
    rates are O(cpus), and cpus will grow without bound as machines advance.

    I'm not sure RCU would help this any; I'd be very much afraid of the
    writes being postponed indefinitely or just too long in the presence
    of what's essentially perpetually in-progress read access. Does RCU
    have a guarantee of forward progress for writers?

    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:30    [W:0.023 / U:0.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site