|
From: Philippe W. <phi...@sk...> - 2011-11-08 22:09:26
|
> So, where did we get to with the fair scheduling? I can't remember the
> final outcome w.r.t. performance loss (if any). Perhaps a conservative
> approach is to add fair scheduling, but have it disabled by default and
> enabled with a command line flag, which we can add to the relevant .vgtest
> files.
>
> J
The summary of state + work to be done as I understand:
* with CPU frequency scaling disabled (i.e. all CPUs always full speed), the last version
of the fair scheduler is slightly faster than the pipe lock.
(work needed: more measurements, a.o. on other platforms than x86/amd64).
* CPU freq scaling however has a much worse impact on the fair scheduler (50% degradation)
than on the pipe scheduler (10..20% degradation)
(work needed: either use sched_setaffinity ( ...) from time to time to ensure all threads
are on the same CPU, then on whatever cpu, then ...
or preferrably a syscall telling: "I want all my threads to have affinity to a single cpu
whatever the cpu and feel free to change it from time to time but not too often" :)
Such a syscall might take years to land in distribution kernels or never land)
* fair scheduler does not link on some distributions (e.g. RHEL 5, when compiling in 32bits),
as not all gcc versions have the needed builtin
(work needed: have replacement assembly code when builtin not available)
(or keep the pipe scheduler in this case)
* (work needed) do an implementation for Darwin
(or keep the pipe scheduler on this platform)
* (work needed) : investigate linkability/behaviour/performance on other platforms
(ARM, ppc, android, ...)
|