mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Qing Wang <wangqing@vivo.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arch_topology: Do not set llc_sibling if llc_id is invalid
Date: Tue, 12 Apr 2022 09:58:39 +0100	[thread overview]
Message-ID: <20220412085839.hkpyookqdl6bcjbn@bogus> (raw)
In-Reply-To: <CAHp75Vc-frdJSAMxK1YpHwmPa_-0fTpRxq=QObcux3Jt=5+9kw@mail.gmail.com>

On Mon, Apr 11, 2022 at 06:07:45PM +0300, Andy Shevchenko wrote:
> On Mon, Apr 11, 2022 at 12:10 PM Qing Wang <wangqing@vivo.com> wrote:
> >
> > From: Wang Qing <wangqing@vivo.com>
> >
> > When ACPI is not enabled, cpuid_topo->llc_id = cpu_topo->llc_id = -1, which
> > will set llc_sibling 0xff(...), this is misleading.
> 
> Shouldn't it be a Fixes tag then?
>

I thought about that. One the file has moved and lot of refactoring before the
move after the code was first introduced. Since no one has seen any issues as
the mask matches all the CPUs on a single chip SoC and this is not user visible,
I didn't push for the fixes tag.

Anyways the original commit introducing the feature is
Commit 37c3ec2d810f ("arm64: topology: divorce MC scheduling domain from core_siblings")
which was merged in v4.18 if I read git log correctly.

I am happy to backport if needed.

> > Don't set llc_sibling(default 0) if we don't know the cache topology.
> 
> ...
> 
> > -               if (cpuid_topo->llc_id == cpu_topo->llc_id) {
> > +               if (cpu_topo->llc_id != -1 && cpuid_topo->llc_id == cpu_topo->llc_id) {
> 
> I'm wondering if more strict check is better here, i.e.
> 
>                if (cpu_topo->llc_id >= 0 && cpuid_topo->llc_id ==
> cpu_topo->llc_id) {
>

Yes I would agree. But I think Qing is just following other similar checks in
the file. All such ids are initialised to -1 and are assigned only valid
values >= 0. I am OK to keep it as is to keep it aligned with other similar
checks.

-- 
Regards,
Sudeep

  reply	other threads:[~2022-04-12 10:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11  2:36 Qing Wang
2022-04-11  8:37 ` Sudeep Holla
2022-04-11  9:32   ` Greg Kroah-Hartman
2022-04-11 15:07 ` Andy Shevchenko
2022-04-12  8:58   ` Sudeep Holla [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-03-28  7:24 Qing Wang

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=20220412085839.hkpyookqdl6bcjbn@bogus \
    --to=sudeep.holla@arm.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=wangqing@vivo.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

all inboxes | Powered by JetHome®