From owner-freebsd-current Wed May 29 0:13:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id E8A9937B40A; Wed, 29 May 2002 00:13:15 -0700 (PDT) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.12.3+3.5Wbeta/3.7W-rina.r-Nankai-Koya) with ESMTP id g4T7DD3i043889 ; Wed, 29 May 2002 16:13:14 +0900 (JST) Message-Id: <200205290713.g4T7DD3i043889@rina.r.dl.itc.u-tokyo.ac.jp> Date: Wed, 29 May 2002 16:13:13 +0900 From: Seigo Tanimura To: John Baldwin Cc: Seigo Tanimura , current@FreeBSD.org Subject: Re: preemption across processors In-Reply-To: References: <200205280810.g4S8Ah3i071756@rina.r.dl.itc.u-tokyo.ac.jp> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 28 May 2002 14:56:04 -0400 (EDT), John Baldwin said: >> The prototype patch is at: >> >> http://people.FreeBSD.org/~tanimura/patches/ippreempt.diff.gz >> >> And the p4 depot >> >> //depot/user/tanimura/ippreempt/... >> >> The patch is for only i386 at the moment. >> >> The following is the brief description of the patch: jhb> I would prefer that this was hung off the preemption stuff I've already done jhb> rather than reinventing it. I would also prefer that we get a preemptive jhb> kernel w/o this done stable before adding extra complication. Or I can integrate your work in //depot/user/jhb/preemption/... into //depot/user/tanimura/ippreempt/... . >> Miscellaneous stuff: >> >> If a thread spins for an adaptive mutex, propagate its priority to the >> owner thread of the mutex. This prevents preemption of the owner >> thread by a thread with the priority in between the owner thread and >> the spinning thread. jhb> Ewww, I'd rather avoid this if possible. This is just an optimization, jhb> but it would depend on how complicated this makes the mutex code to see jhb> if it's worth it or not. The owner thread of an adaptive mutex never lowers its priority until it releases the mutex. We should thus bump the priority of the owner thread not during but just before spinning. However, it is difficult to know if the current thread can spin prior to calling _obtain_lock(). In addition, I would say that spinning can be done even more efficiently. At the moment, we try an atomic test-and-set instruction in each spin. As another thread holds the mutex, we are likely to execute an expensive test-and-set instruction quite a lot of times. Maybe we can solve both of the issues above by roughly checking if a thread can keep spinning without acquiring any locks, in the similar way as we do for a spin mutex. First, test the following conditions: - The owner of the mutex has not changed. - The owner is on a processor. If both of the conditions satisfy, keep spinning. Otherwise, try test-and-set. The pseudo-code would look like this: while (!_obtain_lock(m, td)) { mtx_lock_spin(&sched_lock); if (unowned(m)) { mutex_unlock_spin(&sched_lock); continue; } owner = mtx_owner(m); if (oncpu(owner)) { bump_priority(owner, td); /* Spin without holding sched_lock. */ critical_enter(); mtx_unlock_spin(&sched_lock); while (owner == mtx_owner(m) && oncpu(owner)) { /* Handle interrupts. */ critical_exit(); /* Spin. */ critical_enter(); } critical_exit(); continue; } sleep(td); mutex_unlock_spin(&sched_lock); } The code above does not use any test-and-set instructions, nor does it keep bumping the priority of the owner during spinning. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message