All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 3/4] sched/topology: remove smt_gain
Date: Tue, 4 Sep 2018 03:37:42 -0700	[thread overview]
Message-ID: <20180904103742.GC61288@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180904093626.GA23936@linaro.org>

* Vincent Guittot <vincent.guittot@linaro.org> [2018-09-04 11:36:26]:

> Hi Srikar,
> 
> Le Tuesday 04 Sep 2018 à 01:24:24 (-0700), Srikar Dronamraju a écrit :
> > However after this change, capacity_orig of each SMT thread would be
> > 1024. For example SMT 8 core capacity_orig would now be 8192.
> > 
> > smt_gain was suppose to make a multi threaded core was slightly more
> > powerful than a single threaded core. I suspect if that sometimes hurt
> 
> Is there system with both single threaded and multi threaded core ?
> That was the main open point for me (and for Qais too)
> 

I dont know of any systems that have come with single threaded and
multithreaded. However some user can still offline few threads in a core
while leaving other cores untouched. I dont really know why somebody
would want to do it.  For example, some customer was toying with SMT 3
mode in a SMT 8 power8 box.

> 
> > us when doing load balance between 2 cores i.e at MC or DIE sched
> > domain. Even with 2 threads running on a core, the core might look
> > lightly loaded 2048/8192. Hence might dissuade movement to a idle core.
> 
> Then, there is the sibling flag at SMT level that normally ensures 1 task per
> core for such UC
> 

Agree.

> > 
> > I always wonder why arch_scale_cpu_capacity() is called with NULL
> > sched_domain, in scale_rt_capacity(). This way capacity might actually
> 
> Probably because until this v4.19-rcxx version, the rt scaling was done
> relatively to local cpu capacity:
>   capacity  = arch_scale_cpu() * scale_rt_capacity / SCHED_CAPACITY_SCALE
> 
> Whereas now, it directly returns the remaining capacity
> 
> > be more than the capacity_orig. I am always under an impression that
> > capacity_orig > capacity.  Or am I misunderstanding that?
> 
> You are right, there is a bug for SMT and the patch below should fix it.
> Nevertheless, we still have the problem in some other places in the code.
> 
> Subject: [PATCH] sched/fair: fix scale_rt_capacity() for SMT
> 
> Since commit:
>   commit 523e979d3164 ("sched/core: Use PELT for scale_rt_capacity()")
> scale_rt_capacity() returns the remaining capacity and not a scale factor
> to apply on cpu_capacity_orig. arch_scale_cpu() is directly called by
> scale_rt_capacity() so we must take the sched_domain argument
> 
> Fixes: 523e979d3164 ("sched/core: Use PELT for scale_rt_capacity()")
> Reported-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>

Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>

-- 
Thanks and Regards
Srikar Dronamraju


  reply	other threads:[~2018-09-04 10:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-29 13:19 [PATCH 0/4] sched/numa: remove unused code Vincent Guittot
2018-08-29 13:19 ` [PATCH 1/4] sched/numa: remove unused code from update_numa_stats() Vincent Guittot
2018-09-04  6:39   ` Srikar Dronamraju
2018-09-10 10:19   ` [tip:sched/core] sched/numa: Remove " tip-bot for Vincent Guittot
2018-08-29 13:19 ` [PATCH 2/4] sched/numa: remove unused nr_running field Vincent Guittot
2018-09-04  6:40   ` Srikar Dronamraju
2018-09-10 10:20   ` [tip:sched/core] sched/numa: Remove unused numa_stats::nr_running field tip-bot for Vincent Guittot
2018-08-29 13:19 ` [RFC PATCH 3/4] sched/topology: remove smt_gain Vincent Guittot
2018-08-29 14:08   ` Qais Yousef
2018-08-29 14:42     ` Vincent Guittot
2018-09-07 12:42     ` Peter Zijlstra
2018-09-10 11:23       ` Qais Yousef
2018-09-04  8:24   ` Srikar Dronamraju
2018-09-04  9:36     ` Vincent Guittot
2018-09-04 10:37       ` Srikar Dronamraju [this message]
2018-09-05  7:36         ` Vincent Guittot
2018-09-05  8:50           ` Srikar Dronamraju
2018-09-05  9:11             ` Vincent Guittot
2018-09-05 11:14               ` Srikar Dronamraju
2018-09-06  9:21                 ` Vincent Guittot
2018-09-10 11:05         ` Qais Yousef
2018-09-10 10:07       ` [tip:sched/core] sched/fair: Fix scale_rt_capacity() for SMT tip-bot for Vincent Guittot
2018-12-11 15:31   ` [tip:sched/core] sched/topology: Remove the ::smt_gain field from 'struct sched_domain' tip-bot for Vincent Guittot
2018-08-29 13:19 ` [RFC PATCH 4/4] sched/topology: remove unused sd param from arch_scale_cpu_capacity() Vincent Guittot
2018-08-29 13:19   ` Vincent Guittot

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=20180904103742.GC61288@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --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.