Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Nov 1999 23:03:41 +0100
From:      Poul-Henning Kamp <phk@freebsd.org>
To:        current@freebsd.org
Subject:   PATCH for testing
Message-ID:  <22209.942703421@critter.freebsd.dk>

next in thread | raw e-mail | index | archive | help

http://phk.freebsd.dk/misc/p_args.patch

The p_args.patch patch implements a cache of the commandline arguments
in the process structure and makes ps(1) pick it up from there with
sysctl rather than by groping around in the target process memory.

This patch:
        Speeds up ps(1).

        Reduces the risk of some hairy races in procfs/proc_mem.c
        when multiple ps(1) processes are running on a SMP system

        Moves us closer to makeing procfs optional again (this is
        a nice thing for chroot and jails).

There is a new sysctl: kern.ps_arg_cache_limit which defaults to
(PAGE_SIZE / 8).  This is the max amount of RAM we will use *PER
PROCESS* to cache commandlines in.  If the commandline is longer
*OR* of the process calls setproctitle(3) then nothing will be
cached and ps(1) will have to take the long way though the process
memory to find the command line for it.

Things which need more work:

        Examine if locking will be needed for p->p_args, in particular
        for the refcount element.

        Decide how setproctitle(3) should work.  Do we want to keep
        the "real" commandline around in addition to the proctitle
        or do we just overwrite it as we do now.  I'd like to hear
	input from people on this one.  One option is "as today",
	the other would allow us to see the actual commandline
	in addition to any proctitle the process have set.  The
	down side is that the process nolonger can erase a password
	or similar sensitive arguments.

        Test, test, test...

Poul-Henning
/19991115

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22209.942703421>