Date: Sun, 17 Jan 1999 11:24:38 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jason Evans <jasone@canonware.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Terry Lambert <tlambert@primenet.com>, hackers@FreeBSD.ORG Subject: Re: Path to SMP Message-ID: <199901171924.LAA51387@apollo.backplane.com> References: <Pine.BSF.4.05.9901170057230.27422-100000@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Matthew Dillon initially asked:
:
:> Is anyone currently working on the next big step in the SMP
:> puzzle? That is, implementing kernel threads with preemptive
:> scheduling?
:
:Matthew Dillon continued on to infer that this is all that is necessary in
:order to have good SMP support for threaded applications (assuming the
:Linux definition of kernel threads):
:
:...
:
:Actually, I don't think it's enough to have the ability to run multiple
:"clone()d" processes in supervisor mode, in parallel. The problem is that
:these processes can block in the kernel. For an N->M mapping of
:threads->processes, this means a process can block, thus preventing other
:...
:schedulable user threads from running. In the LinuxThreads model, every
:user thread is associated with a clone()d process, but this doesn't scale
:well, and has the additional problem of slow thread context switches
:...
There is nothing magic about a supervisor-supervisor context switch,
and the overhead of cloning processes exists only because the full
struct proc is being duplicated - also not necessary.
All we really need is the concept of a 'task' verses 'process'. A process
is made up of one or more scheduling entities called 'tasks'. tasks are
trivial to create, switch between, and destroy. I think it can be
that simple.
The problem UNIXs have now is that the scheduling entity is also the
resource management entity, so you start to have to go through loops
to make it efficient.
If interrupts are moved into kernel threads, stack overhead becomes much
more predictable so the stack utilization resource might come in at, say,
8K per thread instead of 16K or 32K per thread. Also, you can still
implement a semi-synchronous cross-thread call without having to deal
with the overhead of a fully-async design.
-Matt
Matthew Dillon
<dillon@backplane.com>
:Jason Evans <jasone@canonware.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901171924.LAA51387>