1:1 threading.

[Jeff Roberson]

On Thu, 27 Mar 2003, Daniel Eischen wrote:

> On Thu, 27 Mar 2003, Scott Long wrote:
> > Once 5-STABLE happens, users of 5.x can no longer be guinea pigs for KSE
> > development.  By keeping the 1:1 and M:N API's separate, KSE can
> > progress in 6-CURRENT until it is proven while still allowing MFC's to
> > 5-STABLE to happen without too much pain.
>
> That's kind of silly; we have other ways to keep API/ABI
> compatability and have used this for all other syscalls.
> The KSE and thread mailboxes even have version numbers
> in them.

Which means they are likely to change.  I do not want to develop on
unstable APIs and unstable kernel code.  kern_thr.c is 254 lines.  I think
we can handle a little duplication.  I'm not sure why the objection is so
strong.

>
> > Later on down the road when
> > KSE matures, or when we decide that 1:1 should really just be a special
> > case of M:N, we can look at addressing the above concerns and possibly
> > MFC'ing the results back to 5-STABLE.  But for now we need to allow for
> > 5-STABLE to actually be usable and maintainable.
>
> The libthr implementation of 1:1 is not what most consider
> 1:1 -- you don't get a separate quantum and priority for
> each thread.  As such, this library is really no different
> than libkse.  The only real difference is that the UTS
> chooses the next thread to run instead of the kernel.
> If you're going to add a bunch of code to both userland
> (in libthr) and the kernel just to get a working threading
> library, it seems much easier to just fix libkse so that
> it works for the single KSE/KSEG case.

It didn't seem much easier to me.

This whole argument about kseg/kse/thread vs kse/thread can be solved very
easily by allocating a ksegrp in kern_thr.c  I estimate that would add
another 10 lines of code.

The ksegrp argument is questionable anyway.  In both ULE and 4bds each KSE
gets its own quantum.  The KSEGRP holds the static priority and the
dynamic user priority which is calculated based on the behavior of the
whole process.  This causes all threads in the process to be penalized for
using cpu at the same rate as a single threaded process using an
equivalent amount of cpu would be.

The effects are less because each thread/kse is given as big of a quantum
as each full process would.  I'm not sure if this is a bug or a feature.

In my opnion the ksegrp is not totally hashed out. I think you may forget
that I have done a fair amount of work on schedulers in freebsd and I do
understand the ramification of the decision that I made.  I do not think
this at all important to have correct prior to having real users using
real threads.

Cheers,
Jeff