Re: ULE 2.0

Jeff Roberson wrote:
> Hello everyone,
> 
> After a considerable vacation from ULE I have come back to address some 
> long standing concerns.  I felt that the old double-queue mechanism 
> caused very unnatural behavior and have finally come up with something 
> I'm happy to replace it with.  I've been working on this off and on for 
> several months now.  Some details are below.  More are at:
> http://jeffr-tech.livejournal.com/3729.html
> 
> The version now in CVS(1.172) should restore ULE's earlier interactive 
> performance under load.  I have tested with a make -j128 kernel while 
> using mozilla and while playing a dvd.  Neither ever skip for me.  nice 
> now has a more gradual effect than before.  It no longer allows the 
> total starvation of processes.  ULE should also be very slightly faster 
> on UP as compared to before.  SMP behavior should have changed very 
> little although I did simplify some small parts of these algorithms.  In 
> general, non-interactive tasks are scheduled much more intelligently 
> although this may not be apparent under most workloads.
> 
> I'm hoping for the following types of feedback from anyone interested in 
> testing:
> 
> 1)  Is the response to nice levels as you would hope?  I think nice +20 
> may not inhibit the nice'd thread enough at the moment.
> 2)  Is the interactive performance satisfactory?
> 3)  Is there any performance degredation for your common tasks?
> 4)  Does the cpu estimator give reasonable results?  See %cpu in top.  
> It is expected that there will be periods where summing up all threads 
> will yield slightly over 100% cpu.
> 
> Any and all feedback is welcome.  Please make sure any problem reports 
> are sent to jroberson_at_chesapeake.net in the to line so I see them more 
> quickly.
> 
> Thanks,
> Jeff

I think it might be not a right way to work on FreeBSD thread scheduler,
it is more important to work out a cpu dispatcher rather than inventing
a dynamic priority algorithm to replace 4BSD's algorithm, the 4BSD
dynamic priority algorithm is still the best one I can find, it provides
very good fairness. the most important thing is there should be a
cpu dispatcher which knows how to place a thread on a cpu with cpu
affinity-aware, maybe multiple runqueues, it knows cpu topology, and
may be NUMA awareness, maybe provide cpu partitions, root can create
and destroy a partition, root can add cpu to the partition or remove
a cpu from the parition or move a cpu from partition a to partition b,
bind applications to a partition etcs. On the top of cpu-dispatcher, 
there could be 4BSD or other dynamic priority alogrithm, but that's
less important than this one. with this thought, I am going to remove 
sched_core as I found the cpu dispatcher is the key thing.

Regards,
David Xu