From owner-cvs-all Wed Sep 20 16:56:55 2000 Delivered-To: cvs-all@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 87EA437B423; Wed, 20 Sep 2000 16:56:51 -0700 (PDT) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id QAA07925; Wed, 20 Sep 2000 16:56:51 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id QAA35379; Wed, 20 Sep 2000 16:56:50 -0700 (PDT) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA20235; Wed, 20 Sep 2000 16:56:50 -0700 (PDT) From: Don Lewis Message-Id: <200009202356.QAA20235@salsa.gv.tsc.tdk.com> Date: Wed, 20 Sep 2000 16:56:49 -0700 In-Reply-To: References: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Robert Watson Subject: Re: cvs commit: src/sys/kern vfs_syscalls.c Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sep 20, 10:11am, Robert Watson wrote: } Subject: Re: cvs commit: src/sys/kern vfs_syscalls.c } } Cool -- I just noticed that code yesterday and intended to take a look at } fixing it. Especially in SMPng-land, that kind of arrangement is scary. } } BTW, at some point we're going to need to figure out locking/etc for } process structures. Right now shared credentials save around 76 bytes per } process structure, and additional space due to references in sockets, open } file records, struct buf (?), sockets, et al. I've been wondering what } the effective cost of moving to an unshared credential model might be, or } to a semi-shared model. By semi-shared, I mean something on the order of } what SGI/IRIX does -- credentials are only shared by entities which by } definition have the same credential (userland threads mapped into multiple } kernel processes, et al). In a realm with locking, credentials might } become contentious as they are accessed frequently during syscalls. Since the credentials are effectively COW, the only additional locked required by sharing should be the reference count, which isn't accessed all that frequently. Either model will require some sort of locking at the entity level in your example to prevent one thread/process from changing the credential or the pointer to the credential while another thread/process is using it. } In particular, if we move to a model where elements of the credentials are } independently refcounted (i.e., uidinfo might be scoped by jail() and } refcounted), it would simplify the model substantially. I'm not sure that it buys us that much. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message