Date: Wed, 29 May 2002 16:13:13 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: John Baldwin <jhb@FreeBSD.org> Cc: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, current@FreeBSD.org Subject: Re: preemption across processors Message-ID: <200205290713.g4T7DD3i043889@rina.r.dl.itc.u-tokyo.ac.jp> In-Reply-To: <XFMail.20020528145604.jhb@FreeBSD.org> References: <200205280810.g4S8Ah3i071756@rina.r.dl.itc.u-tokyo.ac.jp> <XFMail.20020528145604.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 May 2002 14:56:04 -0400 (EDT), John Baldwin <jhb@FreeBSD.org> 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 <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205290713.g4T7DD3i043889>