From: Valentin Schneider <valentin.schneider@arm.com>
To: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, x86@kernel.org,
Len Brown <len.brown@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sudeep Holla <sudeep.holla@arm.com>,
guohanjun@huawei.com, Will Deacon <will@kernel.org>,
linuxarm@huawei.com, Brice Goglin <Brice.Goglin@inria.fr>,
Jeremy Linton <Jeremy.Linton@arm.com>
Subject: Re: [RFC PATCH] topology: Represent clusters of CPUs within a die.
Date: Mon, 19 Oct 2020 14:48:02 +0100 [thread overview]
Message-ID: <jhjh7qqqqct.mognet@arm.com> (raw)
In-Reply-To: <20201019131052.GC8004@e123083-lin>
+Cc Jeremy
On 19/10/20 14:10, Morten Rasmussen wrote:
> Hi Jonathan,
> The problem I see is that the benefit of keeping tasks together due to
> the interconnect layout might vary significantly between systems. So if
> we introduce a new cpumask for cluster it has to have represent roughly
> the same system properties otherwise generic software consuming this
> information could be tricked.
>
> If there is a provable benefit of having interconnect grouping
> information, I think it would be better represented by a distance matrix
> like we have for NUMA.
>
> Morten
That's my queue to paste some of that stuff I've been rambling on and off
about!
With regards to cache / interconnect layout, I do believe that if we
want to support in the scheduler itself then we should leverage some
distance table rather than to create X extra scheduler topology levels.
I had a chat with Jeremy on the ACPI side of that sometime ago. IIRC given
that SLIT gives us a distance value between any two PXM, we could directly
express core-to-core distance in that table. With that (and if that still
lets us properly discover NUMA node spans), we could let the scheduler
build dynamic NUMA-like topology levels representing the inner quirks of
the cache / interconnect layout.
It's mostly pipe dreams for now, but there seems to be more and more
hardware where that would make sense; somewhat recently the PowerPC guys
added something to their arch-specific code in that regards.
WARNING: multiple messages have this Message-ID (diff)
From: Valentin Schneider <valentin.schneider@arm.com>
To: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Len Brown <len.brown@intel.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
x86@kernel.org, guohanjun@huawei.com,
linux-kernel@vger.kernel.org,
Jeremy Linton <Jeremy.Linton@arm.com>,
linuxarm@huawei.com, Brice Goglin <Brice.Goglin@inria.fr>,
linux-acpi@vger.kernel.org,
Jonathan Cameron <Jonathan.Cameron@Huawei.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH] topology: Represent clusters of CPUs within a die.
Date: Mon, 19 Oct 2020 14:48:02 +0100 [thread overview]
Message-ID: <jhjh7qqqqct.mognet@arm.com> (raw)
In-Reply-To: <20201019131052.GC8004@e123083-lin>
+Cc Jeremy
On 19/10/20 14:10, Morten Rasmussen wrote:
> Hi Jonathan,
> The problem I see is that the benefit of keeping tasks together due to
> the interconnect layout might vary significantly between systems. So if
> we introduce a new cpumask for cluster it has to have represent roughly
> the same system properties otherwise generic software consuming this
> information could be tricked.
>
> If there is a provable benefit of having interconnect grouping
> information, I think it would be better represented by a distance matrix
> like we have for NUMA.
>
> Morten
That's my queue to paste some of that stuff I've been rambling on and off
about!
With regards to cache / interconnect layout, I do believe that if we
want to support in the scheduler itself then we should leverage some
distance table rather than to create X extra scheduler topology levels.
I had a chat with Jeremy on the ACPI side of that sometime ago. IIRC given
that SLIT gives us a distance value between any two PXM, we could directly
express core-to-core distance in that table. With that (and if that still
lets us properly discover NUMA node spans), we could let the scheduler
build dynamic NUMA-like topology levels representing the inner quirks of
the cache / interconnect layout.
It's mostly pipe dreams for now, but there seems to be more and more
hardware where that would make sense; somewhat recently the PowerPC guys
added something to their arch-specific code in that regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-19 13:48 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 15:27 [RFC PATCH] topology: Represent clusters of CPUs within a die Jonathan Cameron
2020-10-16 15:27 ` Jonathan Cameron
2020-10-17 6:44 ` Greg Kroah-Hartman
2020-10-17 6:44 ` Greg Kroah-Hartman
2020-10-19 8:08 ` Jonathan Cameron
2020-10-19 8:08 ` Jonathan Cameron
2020-10-19 10:00 ` Brice Goglin
2020-10-19 10:00 ` Brice Goglin
2020-10-19 12:38 ` Jonathan Cameron
2020-10-19 12:38 ` Jonathan Cameron
2020-10-19 10:01 ` Sudeep Holla
2020-10-19 10:01 ` Sudeep Holla
2020-10-19 13:14 ` Jonathan Cameron
2020-10-19 13:14 ` Jonathan Cameron
2020-10-19 10:35 ` Peter Zijlstra
2020-10-19 10:35 ` Peter Zijlstra
2020-10-19 12:32 ` Jonathan Cameron
2020-10-19 12:32 ` Jonathan Cameron
2020-10-19 12:50 ` Peter Zijlstra
2020-10-19 12:50 ` Peter Zijlstra
2020-10-19 13:12 ` Brice Goglin
2020-10-19 13:12 ` Brice Goglin
2020-10-19 13:13 ` Morten Rasmussen
2020-10-19 13:13 ` Morten Rasmussen
2020-10-19 13:10 ` Morten Rasmussen
2020-10-19 13:10 ` Morten Rasmussen
2020-10-19 13:41 ` Jonathan Cameron
2020-10-19 13:41 ` Jonathan Cameron
2020-10-19 14:16 ` Morten Rasmussen
2020-10-19 14:16 ` Morten Rasmussen
2020-10-19 14:42 ` Brice Goglin
2020-10-19 14:42 ` Brice Goglin
2020-10-19 15:30 ` Jonathan Cameron
2020-10-19 15:30 ` Jonathan Cameron
2020-10-19 13:48 ` Valentin Schneider [this message]
2020-10-19 13:48 ` Valentin Schneider
2020-10-19 14:27 ` Jonathan Cameron
2020-10-19 14:27 ` Jonathan Cameron
2020-10-19 15:51 ` Valentin Schneider
2020-10-19 15:51 ` Valentin Schneider
2020-10-19 16:00 ` Jonathan Cameron
2020-10-19 16:00 ` Jonathan Cameron
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=jhjh7qqqqct.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=Brice.Goglin@inria.fr \
--cc=Jeremy.Linton@arm.com \
--cc=Jonathan.Cameron@Huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=guohanjun@huawei.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=sudeep.holla@arm.com \
--cc=will@kernel.org \
--cc=x86@kernel.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.