cvs commit: src/sys/conf files src/sys/ddb db_ps.c src/sys/i386/i386 trap.c src/sys/kern init_main.c kern_synch.c kern_usched.c lwkt_thread.c usched_bsd4.c usched_dummy.c src/sys/sys globaldata.h thread.h usched.h

David Xu bsddiy at 126.com
Sun May 28 22:36:36 PDT 2006


Matthew Dillon wrote:
dillon      2006/05/28 20:57:21 PDT

DragonFly src repository

  Modified files:
    sys/conf             files 
    sys/ddb              db_ps.c 
    sys/i386/i386        trap.c 
    sys/kern             init_main.c kern_synch.c kern_usched.c 
                         lwkt_thread.c usched_bsd4.c 
    sys/sys              globaldata.h thread.h usched.h 
  Added files:
    sys/kern             usched_dummy.c 
  Log:
  Further isolate the user process scheduler data by moving more variables
  from the globaldata structure to the scheduler module(s).
  
  Make the user process scheduler MP safe.  Make the LWKT 'pull thread'
  (to a different cpu) feature MP safe.  Streamline the user process
  scheduler API.
  
  Do a near complete rewrite of the BSD4 scheduler.  Remote reschedules
  (reschedules to other cpus), cpu pickup of queued processes, and locality
  of reference handling should make the new BSD4 scheduler a lot more
  responsive.
  
  Add a demonstration user process scheduler called 'dummy'
  (kern/usched_dummy.c).  Add a kenv variable 'kern.user_scheduler' that
  can be set to the desired scheduler on boot (i.e. 'bsd4' or 'dummy').
  
  NOTE: Until more of the system is taken out from under the MP lock,
  these changes actually slow things down slightly.  Buildworlds are
  about ~2.7% slower.
  
While I am here, can the schedulers allow userspace to specify a cpumask
a thread is willing to run on, some highend software e.g database
systems may want this feature, as they are intend to manager their
CPU locality like they did for RAW device.







More information about the Commits mailing list