Subject: Re: Slow output from 'ps'
To: Gordon Ross <firstname.lastname@example.org>
From: Chris G Demetriou <Chris_G_Demetriou@lagavulin.pdl.cs.cmu.edu>
Date: 07/02/1995 00:45:18
> > The NetBSD version is going to reread things from swap each time,
> > whereas the FreeBSD version will cause other things to be rotated out
> > of the cache the first couple of times. It's a trade off of whether
> > you want to allow ps(1) to be slow, or have it affect the performance
> > of other programs, and whether or not you want procfs to be required.
> Many other modern systems use /proc for ps.
> Are there reasons NetBSD should not do that?
> I generaly like getting away from any use of the old (crufty)
> trick of opening /dev/kmem or /dev/mem and snooping around.
> The /proc fs alternative seems nice an clean by comparison.
I have several comments on this:
(1) no matter what you do, you need to keep the current
interface (or an equivalent one) in place, along with
99% of the code to dig things out of /dev/mem and
(2) making procfs mandatory adds bloat to the kernel.
(3) if procfs _doesn't_ grovel through /dev/mem (i.e.,
if it actually pages in swapped out processes, paged
out args lists, etc.) then you're going to be paging
an awful lot of 'useless' (to the system; by virtue of
the fact that it's been paged out) data in, and also
paging a lot of 'useful' data out. If this doesn't
happen, 'ps' gets no faster. If it _does_ happen,
then 'ps' is capable of hoarding system resources.
I'd rather avoid the bloat in the kernel, and also make users of ps
'pay' directly for the I/O's they incur.
It's also not clear to me that the security implications of a 'useful'
procfs (i.e. one that more uids than 0 can access) have been