Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Nov 2003 06:09:23 -0500 (EST)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        current@freebsd.org
Subject:   Re: More ULE bugs fixed.
Message-ID:  <20031102055955.U10222-100000@mail.chesapeake.net>
In-Reply-To: <20031101035603.G610@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031102055955.U10222-100000>