From owner-freebsd-smp Mon Jul 15 6: 3:11 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42D1337B400 for ; Mon, 15 Jul 2002 06:03:07 -0700 (PDT) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFFE443E6A for ; Mon, 15 Jul 2002 06:03:06 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 17436 invoked from network); 15 Jul 2002 13:03:05 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 15 Jul 2002 13:03:05 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g6FD34048284; Mon, 15 Jul 2002 09:03:04 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020713222131.6ebf07c8.makonnen@pacbell.net> Date: Mon, 15 Jul 2002 09:03:14 -0400 (EDT) From: John Baldwin To: Mike Makonnen Subject: Re: Getting resource limits out from under Giant Cc: freebsd-smp@FreeBSD.ORG, bright@mu.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 14-Jul-2002 Mike Makonnen wrote: > On Sat, 13 Jul 2002 22:50:20 -0400 (EDT) > John Baldwin wrote: > >> >> Why not just do a simple change: don't drop the locks so quick, but go >> ahead and do the modify limit step after using your preallocated >> memory to do the copy-on-write. Then you can drop your locks and free >> any memory using cached pointers. No need for a loop and much >> simpler. Basically, all you need to do is move your 'free some memory' >> step down to the bottom, then you can immediately go from the >> copy-on-write step to the modify limits step. >> > > I do that in kern/kern_acct.c:acct_process(), which only requires an > assignment statemt. But in kern/kern_resource.c:dosetrlimit() there are > 2 reasons why I drop the proc lock. I will defer to your judgement as > to whether they're valid or not. > 1. There is one code path, when changing the stack size limit, where > it goes off into vm land. I thought it might be better to drop the > proc lock so that we don't unnecesarily block other threads. It depends on if vm land can block in that case. > 2. I chose to use a mtx_pool mutex. My understanding is that I may not > aquire another lock while holding one of these. But, as part of > the stack size > limit code path, we aquire a vm_map_lock. While I suppose I could > use > a regular mutex, I thought the additional complexity was worth the > > treadoff in structural/code overhead. At this early stage (relatively) I would prefer to get it working cleanly and optimize it later, but that's just me. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message