1:1 threading.

David Xu davidxu at freebsd.org
Thu Mar 27 17:19:59 PST 2003


----- Original Message ----- 
From: "Jeff Roberson" <jroberson at chesapeake.net>
To: "Daniel Eischen" <eischen at pcnet1.pcnet.com>
Cc: <arch at freebsd.org>; "Scott Long" <scott_long at btc.adaptec.com>
Sent: Friday, March 28, 2003 3:50 AM
Subject: Re: 1:1 threading.


> 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.
> 

do you think that a multithreaded process should use more CPU time then
a single thread process, so threaded process should have higher priority
and block other single thread processes out? AFAIK, threading is not 
designed for this, you may misunderstand what threading is designed for.

> Cheers,
> Jeff
> 
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"



More information about the freebsd-arch mailing list