Re: ULE vs. 4BSD in RELENG_7

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

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

Relevant Pages

  • Re: sched_ule performance on single CPU
    ... listening is not affected by building world while on ... i've recently switched to ULE ... CPU: ... such a load. ...
    (freebsd-stable)
  • Re: ULE 2.0
    ... the priority is not in the kernel or realtime priority range. ... When assigning a thread to a cpu it checks to see if the last cpu it executed on is running a higher priority thread and if so puts it there. ... Balancing by priority indirectly balances by load because threads which have slept for a long time will eventually have a higher priority. ... ULE is that sitting on the run-queue for a long period of time improves your position on the run-queue but not directly your priority. ...
    (freebsd-current)
  • Re: 4BSD/ULE numbers...
    ... September 2005 00:37 CEST schrieb David Xu: ... > advantage is ULE can be HTT friendly if it make it correctly, ... > for example physical / logical CPU balance, ... machines, where it's probably already superior, and I don't really care ...
    (freebsd-current)
  • Re: ULE 2.0
    ... After a considerable vacation from ULE I have come back to address some long standing concerns. ... See %cpu in top. ... and destroy a partition, root can add cpu to the partition or remove ... I feel that working within the framework of the 4BSD scheduler would limit what we can do with these more complex scheduling problems. ...
    (freebsd-current)
  • Re: HEADS UP: ULE is the default scheduler now
    ... Jeff, were you able to clear up the use of ULE on a single CPU machine ... >> ULE has entered into its probationary period as the default scheduler. ... interactivity is reported to be better in many ...
    (freebsd-current)