From owner-freebsd-current@FreeBSD.ORG Thu Apr 3 03:19:42 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A687D37B426; Thu, 3 Apr 2003 03:19:41 -0800 (PST) Received: from pop015.verizon.net (pop015pub.verizon.net [206.46.170.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id B037F43F85; Thu, 3 Apr 2003 03:19:40 -0800 (PST) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.47.167]) by pop015.verizon.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030403111939.QDSE1728.pop015.verizon.net@kokeb.ambesa.net>; Thu, 3 Apr 2003 05:19:39 -0600 Date: Thu, 3 Apr 2003 06:19:38 -0500 From: Mike Makonnen To: freebsd-current@freebsd.org X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at pop015.verizon.net from [138.88.47.167] at Thu, 3 Apr 2003 05:19:39 -0600 Message-Id: <20030403111939.QDSE1728.pop015.verizon.net@kokeb.ambesa.net> Subject: resource limits Giant patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2003 11:19:42 -0000 The following patches at http://people.freebsd.org/~mtm remove process resource limits out from under Giant. I have been bouncing them off jhb for a while now, and I think they are ready. I would appreciate a review/testing.... There are 4 incremental patches for your reviewing pleasure :-) infrastructure.diff - The necessary infrastructure to do the locking users.diff - Modify consumers of resource limits to use the locks giant.diff - actually remove Giant from (most of) those areas regen.diff - Regenerated files, if you don't care to regenerate your own The basic implementation: Each plimit now has an associated mutex. To read an individual limit it is sufficient that the proc lock is held. To modify a limit or in situations where you need a consitent view of a particular limit(s) both the proc lock and the plimit locks are held. Three new functions can be use to get limits: lim_cur(), lim_max(), and lim_rlimit(), that can be used to obtain the current limit, the hard limit, and the entire rlimit structure, respectively. A limit_lock has been defined to protect the following three globals: maxfiles, maxfilesperproc, and maxprocperuid They each now have their own sysctl proc that grabs the limit_lock in order to write them. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9