Messages in this thread | | | Date | Mon, 4 Nov 2002 20:26:17 -0800 | From | jw schultz <> | Subject | Re: ps performance sucks (was Re: dcache_rcu [performance results]) |
| |
On Mon, Nov 04, 2002 at 05:14:19PM -0800, Martin J. Bligh wrote: > I think it's pretty trivial to make /proc/<pid>/psinfo, which > dumps the garbage from all five files in one place. Which makes > it 5 times better, but it still sucks.
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.
> > Don't get me wrong. I believe in the one field per file > > rule but ps &co are the exception that proves (tests) the > > rule. Especially on the heavily laden systems with > > tens of thousands of tasks. We could do with a something > > between /dev/kmem and five files per pid. > > I had a very brief think about this at the weekend, seeing > if I could make a big melting pot /proc/psinfo file that did > seqfile and read everything out in one go, using seq_file > internally to interate over the tasklist. The most obvious > problem that sprung to mind seems to be the tasklist locking - > you obviously can't just hold a lock over the whole thing. > As I know very little about that, I'll let someone else suggest > how to do this, but I'm prepared to do the grunt work of implementing > it if need be.
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.
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.
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws
Remember Cernan and Schmitt - 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/
| |