From owner-freebsd-current Wed May 15 4: 6:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 5564F37B401; Wed, 15 May 2002 04:06:46 -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 g4FB6Z3i059559 ; Wed, 15 May 2002 20:06:35 +0900 (JST) Message-Id: <200205151106.g4FB6Z3i059559@rina.r.dl.itc.u-tokyo.ac.jp> Date: Wed, 15 May 2002 20:06:35 +0900 From: Seigo Tanimura To: jhb@FreeBSD.org Subject: preemption across processors Cc: current@FreeBSD.org, tanimura@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 Currently, a new runnable thread cannot preempt the thread on any processor other than the thread that called mi_switch(). For instance, we do something like the following in _mtx_unlock_sleep(): --- v --- _mtx_unlock_sleep() --- v --- setrunqueue(th_waken_up); if (curthread->preemptable && th_waken_up->priority < curthread->priority) { setrunqueue(curthread); mi_switch(); } --- ^ --- _mtx_unlock_sleep() --- ^ --- If the priority of curthread is higher than th_waken_up, we cannot run it immediately even if there is another processor running a thread with a priority lower than th_waken_up. th_waken_up should preempt that processor, or we would end up with a priority inversion. Maybe we have to dispatch a runnable thread to the processor running a thread with the lowest priority. Solaris seems to take the following steps to do that: 1. If a new thread has slept for longer than 3/100 seconds (this should be tunable), linearly search the processor running a thread with the lowest priority. Otherwise, choose the processor that ran the new thread most recently. 2. Make an inter-processor interrupt to the processor chosen in 1. 3. The chosen processor puts its current thread back to the dispatch queue and performs a context switch to run the new thread. Above is only a rough sketch. We have to watch out for a race of inter-processor interrupts and a processor entering a critical section. If no one is working on preemption across processors, I would like to see if I can do that. Thanks. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message