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

[Martin J. Bligh]

> And i'd still keep environ seperate.  I'm inclined to think
> ps should never have presented it in the first place.
> This is the direction i (for what it's worth) favor.

If it doesn't need it then sure, otherwise just dump whatever
it needs in there. The seperate files would still be there too.
 
> Yep, can't hold the lock across syscalls.  That would be
> quite a bit of data to hold in a per fd buffer.  Think of
> the big iron with tons of processes.

I *have* the big iron with tons of processes ;-) That's why
I care ...
 
> The other way i could see this working is to present it as a
> sparse file.  ps (or whatever) would first get a list of
> pids then iterate over them using lseek to set the file
> offset to pid * CONSTANT_SIZE and read would return
> something smaller than CONSTANT_SIZE bytes.  If the pid no
> longer exists return 0.
> 
> I really hate this idea.  It stinks almost as much as
> /dev/kmem.

Well if we want to be gross and efficient, we could just compile
a kmem-diving dynamic library with every kernel compile and stick
it in /boot or somewhere. Mildly less extreme is a flat index file
for the data you need a la System.map. Then just open /dev/kmem
and grab what you want. Walking the tasklist with no locking would
be an interesting challenge, but probably not insurmountable. 
That's how things like ps always used to work IIRC.

M.