From: Gautham R Shenoy <ego@linux.vnet.ibm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Michael Neuling <mikey@neuling.org>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>,
Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>,
"Oliver O'Halloran" <oohall@gmail.com>,
Nicholas Piggin <npiggin@gmail.com>,
Murilo Opsfelder Araujo <muriloo@linux.ibm.com>,
Anton Blanchard <anton@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 0/3] powerpc: Detection and scheduler optimization for POWER9 bigcore
Date: Sat, 22 Sep 2018 16:33:40 +0530 [thread overview]
Message-ID: <20180922110340.GA1402@in.ibm.com> (raw)
In-Reply-To: <133c7bca-5720-81de-7956-b93870a1bab8@intel.com>
Hi Dave,
On Thu, Sep 20, 2018 at 11:04:54AM -0700, Dave Hansen wrote:
> On 09/20/2018 10:22 AM, Gautham R. Shenoy wrote:
> > -------------------------
> > | L1 Cache |
> > ----------------------------------
> > |L2| | | | |
> > | | 0 | 2 | 4 | 6 |Small Core0
> > |C | | | | |
> > Big |a --------------------------
> > Core |c | | | | |
> > |h | 1 | 3 | 5 | 7 | Small Core1
> > |e | | | | |
> > -----------------------------
> > | L1 Cache |
> > --------------------------
>
> The scheduler already knows about shared caches. Could you elaborate on
> how this is different from the situation today where we have multiple
> cores sharing an L2/L3?
The issue is not so much about the threads in the core sharing L2
cache. But the two group of threads in the core, each of which has its
own L1-cache. This patchset (the second patch in the series) informs
the scheduler of this distinction by defining the SMT sched-domain
have groups correspond to the threads that share L1 cache. With this
the scheduler will treat a pair of threads {1,2} differently from
{1,3} when threads 1 and 3 share the L1 cache, while 1 and 2 don't.
The next sched-domain (CACHE domain) is defined as the group of
threads that share the L2 cache, which happens to be the entire big
core.
Without this patchset, the SMT domain would be defined as the group of
threads that share L2 cache. Thus, the scheduler would treat any two
threads in the big-core in the same way, resulting in run-to-run
variance when the software threads are placed on pair of threads
within the same L1-cache group or on separate ones.
>
> Adding the new sysfs stuff seems like overkill if that's all that you
> are trying to do.
>
The sysfs attributes are to inform the users that we have a big-core
configuration comprising of two small cores, thereby allowing them to
make informed choices should they want to pin the tasks to the CPUs.
--
Thanks and Regards
gautham.
next prev parent reply other threads:[~2018-09-22 11:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-20 17:22 [PATCH v8 0/3] powerpc: Detection and scheduler optimization for POWER9 bigcore Gautham R. Shenoy
2018-09-20 17:22 ` [PATCH v8 1/3] powerpc: Detect the presence of big-cores via "ibm, thread-groups" Gautham R. Shenoy
2018-09-21 3:02 ` [PATCH v8 1/3] powerpc: Detect the presence of big-cores via "ibm,thread-groups" Michael Neuling
2018-09-21 17:17 ` Gautham R Shenoy
2018-09-23 23:48 ` Michael Neuling
2018-09-20 17:22 ` [PATCH v8 2/3] powerpc: Use cpu_smallcore_sibling_mask at SMT level on bigcores Gautham R. Shenoy
2018-09-20 17:22 ` [PATCH v8 3/3] powerpc/sysfs: Add topology/smallcore_thread_siblings[_list] Gautham R. Shenoy
2018-09-21 6:20 ` kbuild test robot
2018-09-21 17:20 ` Gautham R Shenoy
2018-09-20 18:04 ` [PATCH v8 0/3] powerpc: Detection and scheduler optimization for POWER9 bigcore Dave Hansen
2018-09-22 11:03 ` Gautham R Shenoy [this message]
2018-09-25 22:16 ` Dave Hansen
2018-09-26 6:06 ` Gautham R Shenoy
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=20180922110340.GA1402@in.ibm.com \
--to=ego@linux.vnet.ibm.com \
--cc=akshay.adiga@linux.vnet.ibm.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mikey@neuling.org \
--cc=mpe@ellerman.id.au \
--cc=muriloo@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=oohall@gmail.com \
--cc=shilpa.bhat@linux.vnet.ibm.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=svaidy@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).