Messages in this thread |  | | Date | Thu, 7 Nov 2002 23:27:53 -0500 | | From | Daniel Jacobowitz <> | | Subject | Re: ps performance sucks (was Re: dcache_rcu [performance results]) |
| |
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 - 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/
|  |