Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Oct 2007 02:13:57 -0700 (PDT)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        src-committers@freebsd.org, cvs-src@freebsd.org, Jeff Roberson <jeff@freebsd.org>, Garance A Drosehn <gad@freebsd.org>, Ben Kaduk <minimarmot@gmail.com>, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/kern sched_ule.c 
Message-ID:  <20071001020835.B583@10.0.0.1>
In-Reply-To: <20071001172620.X1839@besplex.bde.org>
References:  <20070930040318.094E345018@ptavv.es.net> <20070930153430.U583@10.0.0.1> <20071001172620.X1839@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Oct 2007, Bruce Evans wrote:

> On Sun, 30 Sep 2007, Jeff Roberson wrote:
>
>> On Sat, 29 Sep 2007, Kevin Oberman wrote:
>
>>> YMMV, but ULE seems to generally work better then 4BSD for interactive
>>> uniprocessor systems. The preferred scheduler for uniprocessor servers
>>> is less clear, but many test have shown ULE does better for those
>>> systems in the majority of cases.
>> 
>> I feel it's safe to say desktop behavior on UP is definitely superior.
>
> This is unsafe to say.

Given that the overwhelming amount of feedback by qualified poeple, I 
think it's fair to say that ULE gives a more responsive system under load.

>
>> I think there is no significant difference on UP between 4BSD and ULE
>
> This may be safe to say, but is inconsistent with the above.

I meant no significant difference in performance.  I'm sure there are 
corner case workloads in favor of one or the other.

>
>> except perhaps in context switching microbenchmarks where ULE falls behind.
>
> It is safe to say that interactive users cannot notice insignificant
> differences.  It takes a micro-benchmark to notice possibly-significant
> differences of hundreds or even thousands of nanonseconds for context
> switching.
>
> ULE may give higher priority to interactive processes, but most loss of
> interactivity is caused by blocking on I/O, and there is nothing nothing
> a scheduler can do to speed up slow or overloaded devices.

There is a significant enough class of problems that benefit from the 
improved interactive priorities that people notice it.  I have heard 
reports from a number of laptop users who can run at lower power levels 
using ULE.  I am trivially able to create workloads where 4bsd falls over 
well before ULE.  It is true that io behavior dominates in many cases but 
that's really a seperate issue.

Jeff

>
> Bruce
>



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