Date: Sun, 28 Nov 1999 17:16:04 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: Julian Elischer <julian@whistle.com>, arch@freebsd.org Subject: Re: Threads stuff Message-ID: <199911290116.RAA47293@apollo.backplane.com> References: <Pine.BSF.4.10.9911271542410.544-100000@current1.whistle.com> <3840B1EC.4614AAF0@vigrid.com> <199911281721.JAA45015@apollo.backplane.com> <38417A7F.B23C701D@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:The UTS can treat a page fault in the same way as a blockage on I/O (unless
:the page fault occurs in the scheduler itself). A new thread can be chosen
:and run, and the UTS can be notified when the page fault is cleared.
:
:> * The userland scheduler must deal with scheduling the N cpu case
:> itself - this is something more suitable to the kernel because the
:> userland scheduler has no knowledge of other unrelated
:> processes/threads running in the system. This means that
:> if the userland scheduler is trying to switch or schedule threads
:> without making a system call, the whole mess becomes much more
:> complex when the kernel winds up having to manage the same
:> threads itself.
:
:I think the UTS need only concern itself with its own allocated subprocesses.
:It multiplexes threads onto processes, and it's the kernels job to multiplex
:processes onto CPUs. I think I do agree with you on having to make a system
:call to switch threads, but I'm not completely off the fence yet ;-)
I think this is a big mistake. Scheduling is already a big issue with
KSE's, there is absolutely no need to make it even more complex by having
two scheduling entities -- processes and KSE's when you only really need
to have one -- the KSE's.
We already have to associate kernel state with KSE's, which means we
already have to schedule KSE's. We want maximum parallel execution within
the kernel (once the MP lock becomes fine grained), and we should not have
to rfork() to get it.
There is absolutely no reason why KSE's associated with the same process
cannot be run in parallel, which means that you might as well use KSE's
as your scheduling entity rather then processes.
By attempting to use a process as your scheduling entity you create a
very complex scheduling situation whereby the kernel threads require
completely different code to support then the user threads. I'd rather
have the same code control both - it's easier in concept, design, and
implementation.
There are many, many advantages to using a KSE as your scheduling entity.
You can assign a floating KSE to each cpu and associate it with the
currently running thread. When a context switch occurs, if the KSE's
stack is not in use (i.e. the thread was not blocked in a system call),
you can use the *same* KSE for the next running thread on that cpu. The
result is massive L1/L2 cache sharing for the kernel stack to the point
where you don't even need a kernel stack pre-assigned for your long-idle
processes in some cases (restartable system call case).
-Matt
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?199911290116.RAA47293>