Date: Wed, 24 Nov 1999 11:41:41 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Anthony Kimball <alk@pobox.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <199911241941.LAA20231@apollo.backplane.com> References: <Pine.SUN.3.91.991124134533.26314A-100000@pcnet1.pcnet.com> <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911241941.LAA20231>