ULE vs. 4BSD in RELENG_7

Jeff Roberson jroberson at chesapeake.net
Fri Nov 2 16:31:10 PDT 2007


On Fri, 2 Nov 2007, Josh Carroll wrote:

>> Could you try spot checking a couple of tests with kern.sched.slice set to
>> half its present value?  4BSD on average will use half the slice that ULE
>> will by default.
>
> The initial value was 13, and I changed it to 7. Here is the time
> result for the ffmpeg run:
>
> 13:  1:39.09
> 7:    1:37.01
>
> I also ran it with 4BSD again, as I think I recompiled ffmpeg since my
> previous testing. It ran in:
>
> 1:35.29
>
> So the difference in this workload is only 2.63% when I change the
> slice value to 7. I will re-run my super-smack testing as well and
> reply with the results.

Thank you, that was very useful.  I may have something to test very soon. 
I have a patch that attempts to limit the maximum latency a timesharing 
thread will see based on the cpu load.  It does this by scaling down the 
slice as the system becomes overloaded.

How many ffmpeg instances per cpu core were you running?  It's not clear 
to me why a shorter slice would help if it's 1cpu:1core unless ULE is 
somehow letting idle pagezero run away and do things when it shouldn't.

>
>> This is interesting.  I have had a couple of laptop users report success
>> in using lower power saving modes with ULE.  Are these core temp
>> observations repeatable?
>
> Yes, seem to be. I notice the trend in the graphs whenever I'm booted
> into the ULE kernel for long enough to see a few hours' of data.

What would be interesting to know is if the sum of the temperatures is any 
different.  4BSD gets a much more random distribution of load because a 
thread is run on whatever cpu context switches next.  ULE will have 
specific load patterns since it scans lists of cpus in a fixed order to 
assign load.  So that means it prefers to run on lower numbered cpus if 
they are idle.  This should have a side effect of allowing unused cores to 
powerdown more frequently than with 4BSD although I have not verified this 
in practice.

Jeff

>
> Thanks,
> Josh
> _______________________________________________
> freebsd-performance at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-performance
> To unsubscribe, send any mail to "freebsd-performance-unsubscribe at freebsd.org"
>


More information about the freebsd-performance mailing list