Re: ps performance sucks (was Re: dcache_rcu [performance results])

[Daniel Jacobowitz <dan@debian.org>]

On Thu, Nov 07, 2002 at 11:17:21PM -0500, Robert Love wrote:
> On Thu, 2002-11-07 at 22:57, William Lee Irwin III wrote:
> 
> > 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?
> 
> I am not sure I like the idea of RCU for the tasklist_lock.
> 
> I do agree 100% with your first point, though - the problem is
> ill-behaved readers.  I think the writing vs. reading is such that the
> rw-lock we have now is fine, we just need to make e.g. /proc play way
> way more fair.

If you consider the atomicity that readdir() in /proc needs (that is:
almost none; it needs a guarantee that it will not miss a task which is
alive both before and after the opendir; but that's about it) then
there should be an easy way to augment the pidhash for this sort of
search.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer