From: Valentin Schneider <valentin.schneider@arm.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Aubrey Li <aubrey.li@linux.intel.com>,
mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com,
tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org,
Qais Yousef <qais.yousef@arm.com>,
Jiang Biao <benbjiang@gmail.com>
Subject: Re: [RFC PATCH v2] sched/fair: select idle cpu from idle cpumask in sched domain
Date: Wed, 16 Sep 2020 12:40:55 +0100 [thread overview]
Message-ID: <jhj7dsu54qg.mognet@arm.com> (raw)
In-Reply-To: <20200916110039.GG3117@suse.de>
On 16/09/20 12:00, Mel Gorman wrote:
> On Wed, Sep 16, 2020 at 12:31:03PM +0800, Aubrey Li wrote:
>> Added idle cpumask to track idle cpus in sched domain. When a CPU
>> enters idle, its corresponding bit in the idle cpumask will be set,
>> and when the CPU exits idle, its bit will be cleared.
>>
>> When a task wakes up to select an idle cpu, scanning idle cpumask
>> has low cost than scanning all the cpus in last level cache domain,
>> especially when the system is heavily loaded.
>>
>> The following benchmarks were tested on a x86 4 socket system with
>> 24 cores per socket and 2 hyperthreads per core, total 192 CPUs:
>>
>
> This still appears to be tied to turning the tick off. An idle CPU
> available for computation does not necessarily have the tick turned off
> if it's for short periods of time. When nohz is disabled or a machine is
> active enough that CPUs are not disabling the tick, select_idle_cpu may
> fail to select an idle CPU and instead stack tasks on the old CPU.
>
Vincent was pointing out in v1 that we ratelimit nohz_balance_exit_idle()
by having it happen on a tick to prevent being hammered by a flurry of
idle enter / exit sub tick granularity. I'm afraid flipping bits of this
cpumask on idle enter / exit might be too brutal.
> The other subtlety is that select_idle_sibling() currently allows a
> SCHED_IDLE cpu to be used as a wakeup target. The CPU is not really
> idle as such, it's simply running a low priority task that is suitable
> for preemption. I suspect this patch breaks that.
I think you're spot on.
An alternative I see here would be to move this into its own
select_idle_foo() function. If that mask is empty or none of the tagged
CPUs actually pass available_idle_cpu(), we fall-through to the usual idle
searches.
That's far from perfect; you could wake a truly idle CPU instead of
preempting a SCHED_IDLE task on a warm and busy CPU. I'm not sure if a
proliferation of cpumask really is the answer to that...
next prev parent reply other threads:[~2020-09-16 20:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-16 4:31 [RFC PATCH v2] sched/fair: select idle cpu from idle cpumask in sched domain Aubrey Li
2020-09-16 11:00 ` Mel Gorman
2020-09-16 11:40 ` Valentin Schneider [this message]
2020-09-16 12:04 ` Vincent Guittot
2020-09-17 9:21 ` Li, Aubrey
2020-09-21 15:14 ` Vincent Guittot
2020-09-21 15:21 ` Vincent Guittot
[not found] ` <af0237e0-1451-9d11-2ee2-1468a8bb6180@linux.intel.com>
2020-09-22 7:14 ` Vincent Guittot
[not found] ` <8a86b085-b445-b1c2-9b46-6346d923abf0@linux.intel.com>
2020-09-23 8:50 ` Vincent Guittot
[not found] ` <eb1c4c84-e361-d5a7-d071-b0dd7310eab4@linux.intel.com>
2020-09-24 13:09 ` Vincent Guittot
2020-09-25 9:21 ` Li, Aubrey
2020-09-25 16:45 ` Vincent Guittot
2020-09-27 5:56 ` Li, Aubrey
2020-09-24 16:37 ` Tim Chen
2020-09-24 17:13 ` Phil Auld
2020-09-24 17:43 ` Tim Chen
2020-09-24 17:45 ` Phil Auld
2020-09-25 6:50 ` Vincent Guittot
2020-09-17 9:28 ` [sched/fair] f6005b0d15: netperf.Throughput_Mbps 9.4% improvement kernel test robot
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=jhj7dsu54qg.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=aubrey.li@linux.intel.com \
--cc=benbjiang@gmail.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@linux.intel.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.