Re: cvs commit: src/lib/libthread_xu/thread thr_create.c thr_exit.c thr_info.c thr_kern.c

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:To bring myself up to speed I just read:
:
:http://leaf.dragonflybsd.org/mailarchive/kernel/2005-10/msg00029.html
:(a little old but hopefully still accurate)
:
:Couple layman's questions here: 
:
:1.  Does this LWP<-->Process infrastructure have an impact on BGL removal
:in other areas?  (read:  I don't quite understand the full implications of
:the change, apart from the fact that 1:1 threading now works)
:
:2.  What is the roadmap for BGL removal -- and what's left to do in
:regards to this? 
:
:Just curious...
:Thanks,
:
:James

    It provides a framework in the kernel for determining what needs to be
    locked and what does not need to be locked in order to access to
    certain pieces of structural data.  It will also give us a good idea
    with regards to what bits of per-process data, such as the creds, might
    need to be cached in the lwp structure to remove other lock contention
    from system calls.

    It also provides a good framework to allow us to implement the
    userland scheduler pieces required to properly schedule the threads,
    verses the any-cpu scheduling we have now.

    BGL removal isn't on my personal hotlist for the next release but I
    sure wouldn't mind if someone else wanted to continue the work on it.
    The main bit that I would like to see done is to be able to turn off
    the BGL in the network protocol threads.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>