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>