Date: Wed, 20 Sep 2000 16:56:49 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_syscalls.c Message-ID: <200009202356.QAA20235@salsa.gv.tsc.tdk.com> In-Reply-To: <Pine.NEB.3.96L.1000920100342.61948A-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1000920100342.61948A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009202356.QAA20235>