Date: Fri, 8 Jan 1999 10:59:04 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: Alfred Perlstein <bright@hotjobs.com>, Terry Lambert <tlambert@primenet.com>, dyson@iquest.net, pfgiffun@bachue.usc.unal.edu.co, freebsd-hackers@FreeBSD.ORG Subject: Re: questions/problems with vm_fault() in Stable Message-ID: <199901081859.KAA42987@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
:> Added vm_await() and vm_page_asleep() functions - will be used later.
: ^^^^^^^^
:
:Is this asynchronous wait?
It's a semi-synchronous wait. It is highly experimental - nothing uses it
yet, not even my VM commits after the 15th.
Basically asleep()/await() and then a new flag to the memory subsystem
(and other subsytems, eventually).
asleep() works like tsleep() in that it puts the process on a sleep queue,
but it does *NOT* put the process to sleep. It returns immediately. The
idea is that some deep-down procedure that would otherwise block can now
asleep() and return a temporary error which propogates back up through
the call chain, unwinding any locks as it goes. The high level procedure
that started the whole mess gets the temporary failure and if it wants to
retry the operation it calls await() and then retries.
The initial use of the capability is going to be in the VM system to get
rid of *all* remaining blocking situations in vm/vm_pageout.c and to clean
up vm/vm_fault.c and other VM entities that might block while holding locks
( vm/vm_fault.c must go out of its way right now to release locks when it
retries to avoid deadlock situations. It's a mess ).
The general use of the capability will be to remove all blocking situations
from the deepest subroutines in the kernel - to move them up a procedure
call level or two, which will allow us to start to migrate SMP locks deeper
into the kernel without having to build brain farts.
-Matt
:--
:Daniel C. Sobral (8-DCS)
:dcs@newsguy.com
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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901081859.KAA42987>