|
From: Bart V. A. <bva...@ac...> - 2011-11-10 19:28:58
|
On Wed, Nov 9, 2011 at 11:48 PM, Philippe Waroquiers <phi...@sk...> wrote: > I am wondering if it is a good idea to implement the "sched-setaffinity" > idea to avoid the cpu freq scaling perf. degradation: > A.o. because it looks complex/hacky and also because using sched_setaffinity > will override the affinity requested by the guest process if it also wants > to play with affinity. > > Maybe it would be good enough to just document the cpu freq scaling strange > behaviour, and suggests to either disable cpu frequency scaling when using Valgrind > and/or use taskset to launch valgrind. > > Of course, as usual, the most excellent approach would be to make Valgrind > really (or somewhat more) multi-threaded :). I've implemented what Julian suggested on the bug tracker (https://bugs.kde.org/show_bug.cgi?id=270006): fair scheduling is off by default but can be enabled via a command-line option. Personally I'm not very enthusiast about the sched_setaffinity() approach - I'd rather prefer to document the interaction with frequency scaling. Another option, if someone has the time, is to report on the LKML that we (Valgrind developers) have found a scenario in which the Linux CFS scheduler performs suboptimal. The CFS maintainer, Ingo Molnar, has asked to report such cases some time ago. Maybe Ingo has a suggestion about how to address the performance degradation we observed. If there is no straightforward way to modify the CFS such that the performance degradation we observed can be solved, another possible approach is to add a cgroup configuration variable that allows to restrict all threads of a process to a single CPU. I've had a look at /sys/fs/cgroup on a system with 3.0 kernel (Fedora 16) but at least that kernel 3.0 does not allow to restrict a process to a single CPU without specifying the CPU number. For more information about cgroups, see also http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=Documentation/cgroups. Bart. |