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: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 3/4] sched/topology: remove smt_gain
Date: Wed, 5 Sep 2018 04:14:36 -0700	[thread overview]
Message-ID: <20180905111436.GB57420@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAKfTPtCzznnkR-DDw5DkHYef0nLtB+Yt9UHYMMaJdKD043H7XA@mail.gmail.com>

* Vincent Guittot <vincent.guittot@linaro.org> [2018-09-05 11:11:35]:

> On Wed, 5 Sep 2018 at 10:50, Srikar Dronamraju
> <srikar@linux.vnet.ibm.com> wrote:
> >
> > * Vincent Guittot <vincent.guittot@linaro.org> [2018-09-05 09:36:42]:
> >
> > > >
> > > > 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.
> > >
> > > In this case, it means that we have the same core capacity whatever
> > > the number of CPUs
> > > and a core with SMT 3 will be set with the same compute capacity as
> > > the core with SMT 8.
> > > Does it still make sense ?
> > >
> >
> > To me it make sense atleast from  a power 8 perspective, because SMT 1 >
> > SMT 2 > SMT 4 > SMT8. So if one core is configured for SMT 2 and other
> > core is configured for SMT4; all threads being busy, the  individual
> > threads running on SMT2 core will complete more work than SMT 4 core
> > threads.
> 
> I agree for individual thread capacity but at core group level, the
> core SMT 1 will have the same capacity as core group SMT 8 so load
> balance will try to balance evenly the tasks between the 2 cores
> whereas core SMT 8 > core SMT1 , isn't it ?
> 

I believe that Core capacity irrespective of the number of threads
should be similar. We wanted to give a small benefit if the core has
multiple threads and that was smt_gain. Lets say we have 8 equal sw
threads running on 2 cores; one being SMT 2 and other being SMT4.
then 4 threads should be spread to each core. So that we would be fair
to each of the 8 SW threads.

-- 
Thanks and Regards
Srikar Dronamraju


  reply	other threads:[~2018-09-05 11:14 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
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 [this message]
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=20180905111436.GB57420@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.