From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>,
Michael Neuling <mikey@neuling.org>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>,
linuxppc-dev@lists.ozlabs.org,
Valentin Schneider <valentin.schneider@arm.com>
Subject: Re: [PATCH 3/3] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
Date: Mon, 7 Dec 2020 18:41:38 +0530 [thread overview]
Message-ID: <20201207131138.GJ528281@linux.vnet.ibm.com> (raw)
In-Reply-To: <1607057327-29822-4-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-04 10:18:47]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
>
> +extern bool thread_group_shares_l2;
> /*
> * On big-core systems, each core has two groups of CPUs each of which
> * has its own L1-cache. The thread-siblings which share l1-cache with
> * @cpu can be obtained via cpu_smallcore_mask().
> + *
> + * On some big-core systems, the L2 cache is shared only between some
> + * groups of siblings. This is already parsed and encoded in
> + * cpu_l2_cache_mask().
> */
> static const struct cpumask *get_big_core_shared_cpu_map(int cpu, struct cache *cache)
> {
> if (cache->level == 1)
> return cpu_smallcore_mask(cpu);
> + if (cache->level == 2 && thread_group_shares_l2)
> + return cpu_l2_cache_mask(cpu);
>
> return &cache->shared_cpu_map;
As pointed with lkp@intel.org, we need to do this only with #CONFIG_SMP,
even for cache->level = 1 too.
I agree that we are displaying shared_cpu_map correctly. Should we have also
update /clear shared_cpu_map in the first place. For example:- If for a P9
core with CPUs 0-7, the cache->shared_cpu_map for L1 would have 0-7 but
would display 0,2,4,6.
The drawback of this is even if cpus 0,2,4,6 are released L1 cache will not
be released. Is this as expected?
--
Thanks and Regards
Srikar Dronamraju
WARNING: multiple messages have this Message-ID (diff)
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
Cc: Anton Blanchard <anton@ozlabs.org>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michael Neuling <mikey@neuling.org>,
Nicholas Piggin <npiggin@gmail.com>,
Nathan Lynch <nathanl@linux.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Valentin Schneider <valentin.schneider@arm.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
Date: Mon, 7 Dec 2020 18:41:38 +0530 [thread overview]
Message-ID: <20201207131138.GJ528281@linux.vnet.ibm.com> (raw)
In-Reply-To: <1607057327-29822-4-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2020-12-04 10:18:47]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
>
> +extern bool thread_group_shares_l2;
> /*
> * On big-core systems, each core has two groups of CPUs each of which
> * has its own L1-cache. The thread-siblings which share l1-cache with
> * @cpu can be obtained via cpu_smallcore_mask().
> + *
> + * On some big-core systems, the L2 cache is shared only between some
> + * groups of siblings. This is already parsed and encoded in
> + * cpu_l2_cache_mask().
> */
> static const struct cpumask *get_big_core_shared_cpu_map(int cpu, struct cache *cache)
> {
> if (cache->level == 1)
> return cpu_smallcore_mask(cpu);
> + if (cache->level == 2 && thread_group_shares_l2)
> + return cpu_l2_cache_mask(cpu);
>
> return &cache->shared_cpu_map;
As pointed with lkp@intel.org, we need to do this only with #CONFIG_SMP,
even for cache->level = 1 too.
I agree that we are displaying shared_cpu_map correctly. Should we have also
update /clear shared_cpu_map in the first place. For example:- If for a P9
core with CPUs 0-7, the cache->shared_cpu_map for L1 would have 0-7 but
would display 0,2,4,6.
The drawback of this is even if cpus 0,2,4,6 are released L1 cache will not
be released. Is this as expected?
--
Thanks and Regards
Srikar Dronamraju
next prev parent reply other threads:[~2020-12-07 13:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 4:48 [PATCH 0/3] Extend Parsing "ibm, thread-groups" for Shared-L2 information Gautham R. Shenoy
2020-12-04 4:48 ` [PATCH 0/3] Extend Parsing "ibm,thread-groups" " Gautham R. Shenoy
2020-12-04 4:48 ` [PATCH 1/3] powerpc/smp: Parse ibm, thread-groups with multiple properties Gautham R. Shenoy
2020-12-04 4:48 ` [PATCH 1/3] powerpc/smp: Parse ibm,thread-groups " Gautham R. Shenoy
2020-12-07 12:10 ` Srikar Dronamraju
2020-12-07 12:10 ` Srikar Dronamraju
2020-12-08 17:25 ` Gautham R Shenoy
2020-12-08 17:25 ` Gautham R Shenoy
2020-12-09 3:59 ` [PATCH 1/3] powerpc/smp: Parse ibm, thread-groups " Michael Ellerman
2020-12-09 3:59 ` [PATCH 1/3] powerpc/smp: Parse ibm,thread-groups " Michael Ellerman
2020-12-09 8:35 ` Srikar Dronamraju
2020-12-09 8:35 ` Srikar Dronamraju
2020-12-09 9:05 ` Gautham R Shenoy
2020-12-09 9:05 ` Gautham R Shenoy
2020-12-04 4:48 ` [PATCH 2/3] powerpc/smp: Add support detecting thread-groups sharing L2 cache Gautham R. Shenoy
2020-12-04 4:48 ` Gautham R. Shenoy
2020-12-07 12:40 ` Srikar Dronamraju
2020-12-07 12:40 ` Srikar Dronamraju
2020-12-08 17:42 ` Gautham R Shenoy
2020-12-08 17:42 ` Gautham R Shenoy
2020-12-09 9:14 ` Srikar Dronamraju
2020-12-09 9:14 ` Srikar Dronamraju
2020-12-04 4:48 ` [PATCH 3/3] powerpc/cacheinfo: Print correct cache-sibling map/list for " Gautham R. Shenoy
2020-12-04 4:48 ` Gautham R. Shenoy
2020-12-04 10:32 ` kernel test robot
2020-12-07 13:11 ` Srikar Dronamraju [this message]
2020-12-07 13:11 ` Srikar Dronamraju
2020-12-08 17:56 ` Gautham R Shenoy
2020-12-08 17:56 ` Gautham R Shenoy
2020-12-09 8:39 ` Srikar Dronamraju
2020-12-09 8:39 ` Srikar Dronamraju
2020-12-09 9:07 ` Gautham R Shenoy
2020-12-09 9:07 ` 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=20201207131138.GJ528281@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=ego@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mikey@neuling.org \
--cc=nathanl@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=svaidy@linux.vnet.ibm.com \
--cc=valentin.schneider@arm.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 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.