Messages in this thread | | | Date | Tue, 1 Nov 2022 20:58:20 +0800 | From | Chen Yu <> | Subject | Re: [PATCH] sched: consider WF_SYNC to find idle siblings |
| |
Hi Mel, On 2022-11-01 at 09:41:57 +0000, Mel Gorman wrote: > On Thu, Oct 27, 2022 at 01:26:03PM -0700, Andrei Vagin wrote: > > From: Andrei Vagin <avagin@gmail.com> > > > > WF_SYNC means that the waker goes to sleep after wakeup, so the current > > cpu can be considered idle if the waker is the only process that is > > running on it. > > > > The perf pipe benchmark shows that this change reduces the average time > > per operation from 8.8 usecs/op to 3.7 usecs/op. > > > > Before: > > $ ./tools/perf/perf bench sched pipe > > # Running 'sched/pipe' benchmark: > > # Executed 1000000 pipe operations between two processes > > > > Total time: 8.813 [sec] > > > > 8.813985 usecs/op > > 113456 ops/sec > > > > After: > > $ ./tools/perf/perf bench sched pipe > > # Running 'sched/pipe' benchmark: > > # Executed 1000000 pipe operations between two processes > > > > Total time: 3.743 [sec] > > > > 3.743971 usecs/op > > 267096 ops/sec > > > > The WF_SYNC hint in unreliable as the waking process does not always > go to sleep immediately. While it's great for a benchmark like a pipe > benchmark as the relationship is strictly synchronous, it does not work > out as well for networking which can use WF_SYNC for wakeups but either > multiple tasks are being woken up or the waker does not go to sleep as > there is sufficient inbound traffic to keep it awake. There used to be > an attempt to track how accurate WF_SYNC was, using avg_overlap I think, > but it was ultimately removed. avg_overlap was removed 10 years ago because of accuracy problem that "we are missing the necessary call to update_curr()" according to commit e12f31d3e5d3 ("sched: Remove avg_overlap"). But in current code I think this issue described in above commit does not exist anymore because in current code the put_prev_task() would invoke update_curr() for each entity, then calculating the avg_overlap is always using the update-to-date runtime? If it is true, is it applicable to bring avg_overlap back?
Some benchmarks suffer from cross-CPU wakeup which introduces rq lock contention. Similar to this patch, I tracked the average duration of the task and place the wakee to a CPU where only 1 short-running task is running, which is another direction to mitigate cross-CPU wakeup[1]. Not sure if we could deal with more accurately?
[1] https://lore.kernel.org/lkml/6b81eea9a8cafb7634f36586f1744b8d4ac49da5.1666531576.git.yu.c.chen@intel.com/
thanks, Chenyu
| |