ULE 2.0
David Xu
davidxu at freebsd.org
Thu Jan 4 01:40:44 PST 2007
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
More information about the freebsd-current
mailing list