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 From owner-freebsd-smp Mon Jul 15 9: 4:53 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 B863937B400; Mon, 15 Jul 2002 09:04:50 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B5BC43E58; Mon, 15 Jul 2002 09:04:49 -0700 (PDT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.4/8.12.4) with ESMTP id g6FG4hOn076717; Mon, 15 Jul 2002 12:04:43 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.12.4/8.12.4/Submit) with SMTP id g6FG4gem076714; Mon, 15 Jul 2002 12:04:42 -0400 (EDT) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Mon, 15 Jul 2002 12:04:42 -0400 (EDT) From: "Andrew R. Reiter" To: John Baldwin Cc: Mike Makonnen , freebsd-smp@FreeBSD.ORG, bright@mu.org Subject: Re: Getting resource limits out from under Giant In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Mon, 15 Jul 2002, John Baldwin wrote: : :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. : Working first, optimize later is something I'd prefer as well. Cheers, -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message