Re: ULE 2.0

4BSD is robust,  but I wouldn't say it scales well. The way its decay
scheduling is implemented is very centered around having one queue. The
algorithm also does not have any way of taking more complex topologies
multi-package vs. multi-core vs. multi-thread into account. The scheduler
isn't FreeBSD's biggest scaling problem, but it will definitely wear thin
with time.


         -Kip

On1/4/07, David Xu <davidxu_at_freebsd.org> 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
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>