From: Peter Zijlstra <peterz@infradead.org>
To: Phil Auld <pauld@redhat.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
Mike Galbraith <efault@gmx.de>,
Mel Gorman <mgorman@techsingularity.net>,
Ingo Molnar <mingo@kernel.org>,
Valentin Schneider <valentin.schneider@arm.com>,
Aubrey Li <aubrey.li@linux.intel.com>,
Barry Song <song.bao.hua@hisilicon.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running
Date: Tue, 5 Oct 2021 16:32:28 +0200 [thread overview]
Message-ID: <YVxh/NE2me6ueCNP@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <YVxdPGj92+FcVrgt@lorien.usersys.redhat.com>
On Tue, Oct 05, 2021 at 10:12:12AM -0400, Phil Auld wrote:
> On Tue, Oct 05, 2021 at 12:36:22PM +0200 Peter Zijlstra wrote:
> > On Thu, Sep 23, 2021 at 08:24:03AM -0400, Phil Auld wrote:
> >
> > > It's capped at 8 cpus, which is pretty easy to reach these days, so the
> > > values don't get too large. That scaling is almost a no-op these days.
> >
> > https://lkml.kernel.org/r/YVwdrh5pg0zSv2/b@hirez.programming.kicks-ass.net
> >
> > Ooh, hey, we already fixed that :-)
> >
>
> Thanks Peter.
>
> I'm always a little behind upstream (nature of the job :)
>
> That link leads to a message Id not found.
https://lore.kernel.org/all/YVwblBZ9JBn9vvVr@hirez.programming.kicks-ass.net/T/#u
Seems to work, I must've messed up the copy/paste or something.
> But from what I can see the code that takes the min of online cpus and
> 8 is still present.
Yes, and it should be. I was the confused one. I forgot we added it and
suggested we should add it again :-)
> > So the reasoning there is that if the values get too big, interactiviy
> > get *really* bad, but if you go from say 1 to 4 CPUs, interactivity can
> > improve due to being able to run on other CPUs.
> >
> > At 8 CPUs we end up at 6ms*4=24ms, which is already pretty terrible.
> >
>
> And actually you mention the same thing later on. Most systems, even
> desktops, have 8+ cpus these days so the scaling is mostly not doing
> anything except multiplying by 4, right? So no-op was not the right
> way to describe it maybe. But it's not getting bigger with larger
> numbers of cpus beyond a pretty commonly reached limit.
Yeah, the whole scaling thing is of dubious value these days, the whole
1-8 range is for embedded stuff these days, I mean, only low-end phones
are maybe even still in that range -- oh and my laptop.. :/
next prev parent reply other threads:[~2021-10-05 15:15 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 14:26 [PATCH 0/2] Scale wakeup granularity relative to nr_running Mel Gorman
2021-09-20 14:26 ` [PATCH 1/2] sched/fair: Remove redundant lookup of rq in check_preempt_wakeup Mel Gorman
2021-09-21 7:21 ` Vincent Guittot
2021-09-21 7:53 ` Mel Gorman
2021-09-21 8:12 ` Vincent Guittot
2021-09-21 8:21 ` Peter Zijlstra
2021-09-21 10:03 ` Mel Gorman
2021-09-20 14:26 ` [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running Mel Gorman
2021-09-21 3:52 ` Mike Galbraith
2021-09-21 5:50 ` Mike Galbraith
2021-09-21 7:04 ` Mike Galbraith
2021-09-21 10:36 ` Mel Gorman
2021-09-21 12:32 ` Mike Galbraith
2021-09-21 14:03 ` Mel Gorman
2021-10-05 9:24 ` Peter Zijlstra
2021-09-22 5:22 ` Mike Galbraith
2021-09-22 13:20 ` Mel Gorman
2021-09-22 14:04 ` Mike Galbraith
2021-09-22 14:15 ` Vincent Guittot
2021-09-22 15:04 ` Mel Gorman
2021-09-22 16:00 ` Vincent Guittot
2021-09-22 17:38 ` Mel Gorman
2021-09-22 18:22 ` Vincent Guittot
2021-09-22 18:57 ` Mel Gorman
2021-09-23 1:47 ` Mike Galbraith
2021-09-23 8:40 ` Vincent Guittot
2021-09-23 9:21 ` Mike Galbraith
2021-09-23 12:41 ` Vincent Guittot
2021-09-23 13:14 ` Mike Galbraith
2021-09-27 11:17 ` Mel Gorman
2021-09-27 14:17 ` Mike Galbraith
2021-10-04 8:05 ` Mel Gorman
2021-10-04 16:37 ` Vincent Guittot
2021-10-05 7:41 ` Mel Gorman
2021-09-27 14:19 ` Vincent Guittot
2021-09-27 15:02 ` Mel Gorman
2021-09-23 12:24 ` Phil Auld
2021-10-05 10:36 ` Peter Zijlstra
2021-10-05 14:12 ` Phil Auld
2021-10-05 14:32 ` Peter Zijlstra [this message]
2021-10-05 10:28 ` Peter Zijlstra
2021-10-05 10:23 ` Peter Zijlstra
2021-10-05 9:41 ` Peter Zijlstra
2021-09-22 15:05 ` Vincent Guittot
2021-10-05 9:32 ` Peter Zijlstra
2021-10-03 3:07 ` wakeup_affine_weight() is b0rked - was " Mike Galbraith
2021-10-03 7:34 ` Barry Song
2021-10-03 14:52 ` Mike Galbraith
2021-10-03 21:06 ` Barry Song
2021-10-04 1:49 ` Mike Galbraith
2021-10-04 4:34 ` Mike Galbraith
2021-10-04 9:06 ` Mike Galbraith
2021-10-05 7:47 ` Mel Gorman
2021-10-05 8:42 ` Mike Galbraith
2021-10-05 9:31 ` Mel Gorman
2021-10-06 6:46 ` Mike Galbraith
2021-10-08 5:06 ` Mike Galbraith
2021-09-21 8:03 ` Vincent Guittot
2021-09-21 10:45 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YVxh/NE2me6ueCNP@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aubrey.li@linux.intel.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=pauld@redhat.com \
--cc=song.bao.hua@hisilicon.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.