Messages in this thread |  | | Date | Thu, 7 Nov 2002 19:57:24 -0800 | | From | William Lee Irwin III <> | | Subject | Re: 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?
Thanks, Bill - 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/
|  |