From owner-freebsd-current Mon Nov 15 14: 3:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id E17DD14DB6 for ; Mon, 15 Nov 1999 14:03:47 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id XAA22211 for ; Mon, 15 Nov 1999 23:03:41 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: PATCH for testing From: Poul-Henning Kamp Date: Mon, 15 Nov 1999 23:03:41 +0100 Message-ID: <22209.942703421@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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