From owner-freebsd-arch Wed Nov 24 11:46:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 5047315413 for ; Wed, 24 Nov 1999 11:46:17 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA09079 for ; Wed, 24 Nov 1999 20:45:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35431 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:45:42 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 68EDC1539F for ; Wed, 24 Nov 1999 11:42:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA20231; Wed, 24 Nov 1999 11:41:41 -0800 (PST) (envelope-from dillon) Date: Wed, 24 Nov 1999 11:41:41 -0800 (PST) From: Matthew Dillon Message-Id: <199911241941.LAA20231@apollo.backplane.com> To: Anthony Kimball Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :It would be nice to keep an eye out for the future... SMP :coscheduling of threads. I'd like to see FreeBSD become the OS of the :fastest computer in the world. Making it easy to coschedule threads :(or processes for that matter) would go a long way towards displacing :Linux in this category. Coscheduling is a fairly simple mechanism to implement. No real special cases need to be added to the scheduler itself, you simply ensure that it is 'most likely' for the threads to be scheduled together by placing them next to each other in the run queue. For example, if you have a single scheduling queue (which I really think is what we want) and the scheduler on each cpu picks off the next ready thread from the same queue, and two threads wakeup simultaniously, you can construct the queueing code such that it is highly likely that the two threads will each be (nearly) simultaniously assigned a different cpu and be able to run in parallel. Coscheduling becomes utterly trivial to accomplish if you are using a fractional fair-share scheduler with a single circular linked list of runnable (and running) threads. This is because you can insert a new thread anywhere in the list you wish without creating a hogging sleep/wakeup hogging situation. Thus you can group tasks together fairly easily, even if they have different priorities, and you can even insert special scheduling synchronization entities to handle stabilization issues. A scheduling synchronization entity is a dummy thread for which the context switch is minimal. The thread is responsible for doing special scheduling protocols for the following N threads on the list. The 'real' scheduler winds up not having to do anything special. The dummy thread doesn't really run in a real context and only runs long enough to schedule the next few entities in a special manner. Typically I implement my schedulers using the 'ret' trick. The entity going to sleep pushes whatever context needs to be saved and then pushes the 'restore' vector onto its stack, stores the stack pointer in the task, and then switches to the next task. To restore the context of the task being switched to, the scheduler simply loads the stack pointer from the task structure and issues a 'RET'. This way you can implement a number of special cases as scheduling entities (without any of the overhead) rather then within the scheduler core itself. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message