Date: Sun, 20 Dec 1998 00:13:09 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: asleep()/await(), M_AWAIT, etc... Message-ID: <199812200813.AAA30210@apollo.backplane.com> References: <199812191115.DAA12134@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:One case that I thought of could cause you to spin.
:
: lock object (succeeds)
: MALLOC(..., M_AWAIT) (succeeds)
: MALLOC(..., M_AWAIT) (fails)
:
:After the second MALLOC fails, you'll free the first chunk of memory allocated
:and unlock the object. When you call await(), it'll succeed because memory
:is available because of the memory that was just freed. The first MALLOC()
:will succeed, and the second one will fail again. The way this code is
:written, it looks like only two levels, but it really is 3 by your criteria
:and thus is getting into questionable territory.
Hmm. This could theoretically cause a problem but the hysteresis in the
memory subsystem ought to handle most cases. Still, I can see
a potential problem if the allocation is big enough (i.e. larger then a
few pages).
:} describe is precisely the already-existant situation that asleep() and
:} await() can be used to fix. This might sound expensive, but most
:} of the places where we would need to use asleep()/await() would not
:} actually have to pop back more then a few subroutine levels to be
:} effective.
:
:For pathname traversal, if you give up a lock, I think you have to restart
:from the beginning.
This one could be solved by allocating a forward-looking namei entry
to placemark the blocked operation. So if you are traversing a/b/c/d and
while holding b you miss c, you would allocate a namei record for c to
placemark the I/O and release b, then block normally (i.e. just use
tsleep()). This would prevent a cascade. I do not think there are any
path-oriented syscalls that need to lock a vnode prior to resolving the
path, so asleep()/await() would not be necessary anyway.
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812200813.AAA30210>