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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to