Date: Mon, 15 Jul 2002 12:04:42 -0400 (EDT) From: "Andrew R. Reiter" <arr@watson.org> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Mike Makonnen <makonnen@pacbell.net>, freebsd-smp@FreeBSD.ORG, bright@mu.org Subject: Re: Getting resource limits out from under Giant Message-ID: <Pine.NEB.3.96L.1020715120416.76683A-100000@fledge.watson.org> In-Reply-To: <XFMail.20020715090314.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.ORG> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020715120416.76683A-100000>