Date: Sat, 13 Jul 2002 22:21:31 -0700 From: Mike Makonnen <makonnen@pacbell.net> To: John Baldwin <jhb@FreeBSD.ORG> Cc: bright@mu.org, freebsd-smp@FreeBSD.ORG Subject: Re: Getting resource limits out from under Giant Message-ID: <20020713222131.6ebf07c8.makonnen@pacbell.net> In-Reply-To: <XFMail.20020713225020.jhb@FreeBSD.org> References: <20020713152319.75c416a2.makonnen@pacbell.net> <XFMail.20020713225020.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.
Cheers,
Mike Makonnen
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?20020713222131.6ebf07c8.makonnen>