Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Sep 2000 08:50:01 -0700 (PDT)
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        arch@freebsd.org
Subject:   Request for review: restructuring of per-uid resource limits
Message-ID:  <200009031550.IAA19487@salsa.gv.tsc.tdk.com>

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

The current implemention of the per-uid resource limits has some problems:

	Increases and decreases in the size of socket buffers and the
	creation and destruction of processes (calls to chgsbsize() and
	chgproccnt()) happen much more frequently than credential changes,
	but the chgsbsize() and chgproccnt() do a hash lookup of the
	uidinfo structure on the fly for each call.  This is especially
	bad in the case of chgsbsize() which may be called from an
	interrupt context.  It would be much more efficient to do the
	lookups and save the pointers to the uidinfo structures when
	credentials are changed and just follow the pointers to update
	the resource consumption.

	chgsbsize() can be called from an interrupt context, when the
	hash table may be in an inconsistent state.  Changes to the
	hash table could be protected by splnet(), but that hurts
	performance by increasing the amount of time that interrupts
	are blocked.

	Under certain circumstances it might be possible for chgsbsize()
	to call MALLOC(..., M_WAITOK), which would be bad if done in an
	interrupt context.

	Most of this code probably belongs in kern_resource.c rather
	than kern_proc.c.


The patch at <http://people.freebsd.org/~truckman/uidinfo.patch2000_00_03_1>;
fixes the above problems, at the expense of a little more memory and
some extra messyness in a few other parts of the code.  The only real
uglyness is in kern_prot.c, which should probably have some duplicate
code sequences moved to separate functions.  The chgproccnt() and
chgsbsize() functions are a lot cleaner should be quite a bit faster.

I applied this patch to a couple day old version of -current.  It
compiles without any extra warnings, and seems to run ok under the
light testing that I've done.


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




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