From: Peter Zijlstra <peterz@infradead.org>
To: subhra mazumdar <subhra.mazumdar@oracle.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
steven.sistare@oracle.com, dhaval.giani@oracle.com
Subject: Re: [RFC PATCH V2] sched: Improve scalability of select_idle_sibling using SMT balance
Date: Mon, 8 Jan 2018 23:18:51 +0100 [thread overview]
Message-ID: <20180108221851.GV29822@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20180108221237.31761-1-subhra.mazumdar@oracle.com>
On Mon, Jan 08, 2018 at 02:12:37PM -0800, subhra mazumdar wrote:
> @@ -2751,6 +2763,31 @@ context_switch(struct rq *rq, struct task_struct *prev,
> struct task_struct *next, struct rq_flags *rf)
> {
> struct mm_struct *mm, *oldmm;
> + int this_cpu = rq->cpu;
> + struct sched_domain *sd;
> + int prev_busy, next_busy;
> +
> + if (rq->curr_util == UTIL_UNINITIALIZED)
> + prev_busy = 0;
> + else
> + prev_busy = (prev != rq->idle);
> + next_busy = (next != rq->idle);
> +
> + /*
> + * From sd_llc downward update the SMT utilization.
> + * Skip the lowest level 0.
> + */
> + sd = rcu_dereference_sched(per_cpu(sd_llc, this_cpu));
> + if (next_busy != prev_busy) {
> + for_each_lower_domain(sd) {
> + if (sd->level == 0)
> + break;
> + sd_context_switch(sd, rq, next_busy - prev_busy);
> + }
> + }
> +
No, we're not going to be adding atomic ops here. We've been arguing
over adding a single memory barrier to this path, atomic are just not
going to happen.
Also this is entirely the wrong way to do this, we already have code
paths that _know_ if they're going into or coming out of idle.
next prev parent reply other threads:[~2018-01-08 22:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 22:12 [RFC PATCH V2] sched: Improve scalability of select_idle_sibling using SMT balance subhra mazumdar
2018-01-08 22:18 ` Peter Zijlstra [this message]
2018-01-09 14:50 ` Steven Sistare
2018-01-11 2:09 ` Subhra Mazumdar
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=20180108221851.GV29822@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dhaval.giani@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=steven.sistare@oracle.com \
--cc=subhra.mazumdar@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox