Re: ULE vs. 4BSD in RELENG_7

Josh, thanks for your help so far. This has been very useful.

You're welcome, glad to help! Thanks for the effort and the patch.

Any testing you can run this through is appreciated. Anyone else lurking
in this thread who would like to is also welcome to report back findings.

Here are a few benchmarks comparing ULE and the patched ULE. I
experimented in changing the slice_min value from 2 to 4, in case that
might be useful info for you. Hopefully that helps a bit, but if not
it's just a few minutes of CPU time wasted :)

Sysbench results:
# threads slice=7 slice=13 slice_min=4 slice_min=2
4 2265.67 2250.36 2261.71 2297.08
8 2300.25 2310.02 2306.79 2313.61
12 2269.54 2304.04 2296.54 2279.73
16 2249.26 2252.04 2260.53 2245.76

It looks like with the default minimum (2), the performance for systat
is better with 4 and 8 threads (on a 4 core system), but worse for 12
and 16 threads.

Here are the results for ffmpeg (-threads 8):

slice=7 slice=13 slice_min=4 slice_min=2
1:37.00 1:39.09 1:38.12 1:38.06

The patch definitely improves things there, though not quite as good
as using a slice value of 7. But it does improve things. So it
slightly improves things for ffmpeg and also slightly increases the
performance of sysbench/MySQL (with 8 threads).

I also ran through buildworld for both slice_min of 2 and 4, and here
are the results, again with ULE as a base line:

slice=7 slice=13 slice_min=4 slice_min=2
13:40.56 13:44.28 13:46.64 13:45.80

So buildworld performance is about the same as with the default ULE
and default slice value.

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"

Relevant Pages

  • [PATCH] dvb-core: ULE fixes and RFC4326 additions (kernel 2.6.16)
    ... The original ULE code was based on a draft. ... With these fixes, and some additions (which are included in the patch), the decaps code should now be complient to RFC4326. ... Function is called after a successful CRC32 verification of an ULE SNDU to complete its decoding. ... Added check of return value from functions which handle mandatory extension headers ...
    (Linux-Kernel)
  • Re: ULE/SCHED_SMP diff for 7.0
    ... This patch is scheduled for inclusion in 7.0. ... ULE with SCHED_SMP, which will now no longer exist as a seperate fork ... this is still a very suitable scheduler for uniprocessor ... He holds her helpless breast upon his breast." ...
    (freebsd-current)
  • Re: ULE/SCHED_SMP diff for 7.0
    ... JR> This patch is scheduled for inclusion in 7.0. ... This patch replaces ULE with SCHED_SMP, ... this is still a very suitable scheduler for uniprocessor machines ... make -j3 buildworld buildkernel time degraded by 7%: ...
    (freebsd-current)
  • Re: ULE/SCHED_SMP diff for 7.0
    ... I would like anyone who cares to run it to validate that it does not create any stability or performance regression over the existing ULE. ... This patch replaces ULE with SCHED_SMP, which will now no longer exist as a seperate fork of ULE. ... this is still a very suitable scheduler for uniprocessor machines while providing stronger affinity and other performance improvements for multiprocessor machines. ... real memory = 1063849984 ...
    (freebsd-current)
  • Re: ULE/SCHED_SMP diff for 7.0
    ... This patch is scheduled for inclusion in 7.0. ... This patch replaces ULE ... The new ULE scheduler works fine ... could still extract the attached backtrace. ...
    (freebsd-current)