From owner-freebsd-current Sun Dec 20 00:13:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA16922 for freebsd-current-outgoing; Sun, 20 Dec 1998 00:13:13 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA16916 for ; Sun, 20 Dec 1998 00:13:11 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id AAA30210; Sun, 20 Dec 1998 00:13:09 -0800 (PST) (envelope-from dillon) Date: Sun, 20 Dec 1998 00:13:09 -0800 (PST) From: Matthew Dillon Message-Id: <199812200813.AAA30210@apollo.backplane.com> To: Don Lewis Cc: freebsd-current@FreeBSD.ORG Subject: Re: asleep()/await(), M_AWAIT, etc... References: <199812191115.DAA12134@salsa.gv.tsc.tdk.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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. (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