Re: ULE 2.0

2007/1/4, Scott Long <scottl_at_samsco.org>:
> David Xu wrote:
> > 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
> >
>
> It sounds like you want the linux O(1) scheduler.  It would be very
> interesting to see this applied to FreeBSD.
>
> Scott

Well, sched_core has a lot of the Linux scheduler features.
I think what really David want are 2 layers (dispatching/topology)
independent by the "scheduling" algorithms.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein