From owner-freebsd-current Sat Dec 19 02:06:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA20158 for freebsd-current-outgoing; Sat, 19 Dec 1998 02:06:01 -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 CAA20141 for ; Sat, 19 Dec 1998 02:05:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id CAA07224; Sat, 19 Dec 1998 02:05:54 -0800 (PST) (envelope-from dillon) Date: Sat, 19 Dec 1998 02:05:54 -0800 (PST) From: Matthew Dillon Message-Id: <199812191005.CAA07224@apollo.backplane.com> To: Archie Cobbs Cc: freebsd-current@FreeBSD.ORG Subject: Re: asleep()/await(), M_AWAIT, etc... References: <199812190809.AAA27615@bubba.whistle.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Matthew Dillon writes: :> We add an asleep() kernel function to complement tsleep(). asleep() :> works like tsleep() in that it adds the process to the appropriate :> slpque, but asleep() does *not* put the process to sleep. Instead it :> returns immediately. The process stays runnable. Additional calls :> to asleep() (or a call to tsleep()) removes the proc from any slpque :> and re-adds it to the new one. i.e. only the most recent call is :> effective. :> :> We add an await() kernel function. This function initiates any timeout :> and puts the process to sleep, but only if it is still on a sleep queue. :> If someone (i.e. an interrupt) wakes up the sleep address after the :> process calls asleep() but before it calls await(), the slpque is :> cleared and the await() winds up being a NOP. : :Hmm.. sounds interesting. Seems like one problem is that most :function calls have the semantics that they don't return until :the job they are supposed to do is finished. This would change. : :So you would have to adjust all the upper layer functions to take :account of this change in semantics (they'd have to know to call :await() at the least, of course). : :Also, this only works once; you can't call two subroutines :in a row that both call asleep(), because the second asleep() :will erase the first. : :But in certain cases where you don't need to hold a lock for :the duration of the lengthy operation it would definitely help :reduce contention. : :It would be interesting to see a list of specific cases where :this could be used and would make a significant difference. It's something we could work on from the bottom-up. We would not have to change everything at once. For example, giving the (kernel) malloc an M_AWAIT capability would require fixing kmem_malloc and vm_page_alloc, but nothing else. We can then 'fix' routines that call malloc individually (and then only if necessary or prudent). Those routines can still maintain the fully-synchronous semantics their callers expect and still use the new malloc feature. Ultimately the capability can be propogated back further, especially with those functions that are already passed a flags argument and can thus operate both fully synchronously and semi-synchronously. Truth be said, we don't want to necessarily change the semantics for all the routines to be totally asynchronous - probably 80% of the cases can remain synchronous because they guarentee the lock order. Ultimately I think around 20% of the current code would benefit from a new locking scheme, especially when SMP locks are brought in further. The biggest use of the feature would be the short-term unwinding of locks in order to be able to block without holding any (or too many), and the second biggest use would be to unwind an upper-level lock when we fail to get a lower-level lock in a non-blocking fashion (i.e. unwind a potential deadlock) in order to retry both locks later when we 'might' be able to get the inner lock again. ( This situation is actually somewhat more complex since the issue of deadlock detection is rather complex, but it would solve most 2-level deadlock situations almost trivially ). -Matt :-Archie : :___________________________________________________________________________ :Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com : 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