Messages in this thread | | | Date | Mon, 27 Sep 2021 16:02:40 +0100 | From | Mel Gorman <> | Subject | Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running |
| |
On Mon, Sep 27, 2021 at 04:19:00PM +0200, Vincent Guittot wrote: > On Mon, 27 Sept 2021 at 13:17, Mel Gorman <mgorman@techsingularity.net> wrote: > > > > On Thu, Sep 23, 2021 at 02:41:06PM +0200, Vincent Guittot wrote: > > > On Thu, 23 Sept 2021 at 11:22, Mike Galbraith <efault@gmx.de> wrote: > > > > > > > > On Thu, 2021-09-23 at 10:40 +0200, Vincent Guittot wrote: > > > > > > > > > > a 100us value should even be enough to fix Mel's problem without > > > > > impacting common wakeup preemption cases. > > > > > > > > It'd be nice if it turn out to be something that simple, but color me > > > > skeptical. I've tried various preemption throttling schemes, and while > > > > > > Let's see what the results will show. I tend to agree that this will > > > not be enough to cover all use cases and I don't see any other way to > > > cover all cases than getting some inputs from the threads about their > > > latency fairness which bring us back to some kind of latency niceness > > > value > > > > > > > Unfortunately, I didn't get a complete set of results but enough to work > > with. The missing tests have been requeued. The figures below are based > > on a single-socket Skylake machine with 8 CPUs as it had the most set of > > results and is the basic case. > > > > The reported kernels are > > > > vanilla: vanilla 5.15-rc1 > > sched-scalewakegran-v2r4: My patch > > sched-moveforward-v1r1: Vincent's patch > > I imagine that this is the results for the 1st version which scales > with the number of CPUs >
Yes, the v1r5 results were incomplete and had to be requeued.
-- Mel Gorman SUSE Labs
| |