Re: More ULE bugs fixed.

On Sat, 1 Nov 2003, Bruce Evans wrote:

> On Fri, 31 Oct 2003, Jeff Roberson wrote:
>
> > I have commited my SMP fixes.  I would appreciate it if you could post
> > update results.  ULE now outperforms 4BSD in a single threaded kernel
> > compile and performs almost identically in a 16 way make.  I still have a
> > few more things that I can do to improve the situation.  I would expect
> > ULE to pull further ahead in the months to come.
>
> My simple make benchmark now takes infinitely longer with ULE under SMP,
> since make -j 16 with ULE under SMP now hangs nfs after about a minute.
> 4BSD works better.  However, some networking bugs have developed in the
> last few days.  One of their manifestations is that SMP kernels always
> panic in sbdrop() on shutdown.
>
> > The nice issue is still outstanding, as is the incorrect wcpu reporting.
>
> It may be related to nfs processes not getting any cycles even when there
> are no niced processes.
>

I've just run your script myself.  I was using sched_ule.c rev 1.75.  I
did not encounter any problem.  I also have not run it with 4BSD so I
don't have any performance comparisons.  Hopefully the next time you have
an opportunity to test things will go smoothly.  I fixed a bug in
sched_prio() that may have caused this behavior.

You commented on the nice cutoff before.  What do you believe the correct
behavior is?  In ULE I went to great lengths to be certain that I emulated
the old behavior of denying nice +20 processes cpu time when anything nice
0 or above was running.  As a result of that, nice -20 processes inhibit
any processes with a nice below zero from receiving cpu time.  Prior to a
commit earlier today, nice -20 would stop nice 0 processes that were
non-interactive.  I've changed that though so nice 0 will always be able
to run, just with a small slice.  Based on your earlier comments, you
don't believe that this behavior is correct, why, and what would you like
to see?

Thanks,
Jeff



> Bruce
> _______________________________________________
> 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"
>