Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190226062012.23746-1-lenb@kernel.org> <20190226185358.GQ2861@worktop.programming.kicks-ass.net>
 <20190307145925.GD19434@e105550-lin.cambridge.arm.com> <alpine.DEB.2.21.1904052033220.1802@nanos.tec.linutronix.de>
In-Reply-To: <alpine.DEB.2.21.1904052033220.1802@nanos.tec.linutronix.de>
From:   Len Brown <lenb@kernel.org>
Date:   Fri, 12 Apr 2019 15:52:58 -0400
Message-ID: <CAJvTdK=DNUmOLb9QBHVxn_EAL33zisH-_ZPo8GfFa++5hrK5zQ@mail.gmail.com>
Subject: Re: [PATCH 0/14] v2 multi-die/package topology support
To:     Thomas Gleixner <tglx@linutronix.de>
Cc:     Morten Rasmussen <morten.rasmussen@arm.com>,
        Peter Zijlstra <peterz@infradead.org>, X86 ML <x86@kernel.org>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> > > I think I prefer 's/threads/cpus/g' on that. Threads makes me think SMT,
> > > and I don't think there's any guarantee the part in question will have
> > > SMT on.
> >
> > I think 'threads' is a bit confusing as well. We seem to be using 'cpu'
> > everywhere for something we can schedule tasks on, including the sysfs
> > /sys/devices/system/cpu/ subdirs for each SMT thread on SMT systems.

I agree with Peter and Morten.
"cpu" is more clear and consistent than "thread" here.
I'll spin the series with that string changed.

> > Another thing that I find confusing is that with this series we a new
> > die id/mask which is totally unrelated to the DIE level in the
> > sched_domain hierarchy. We should rename DIE level to something that
> > reflects what it really is. If we can agree on that ;-)
> >
> > NODE level?

Cache topology and node interconnect topology impact performance, and so
we what we look at, when we decided to run something on this CPU or that one.

That logical topology lives within the physical package and die topology,
but doesn't necessarily match it.  For example, caches can be shared
or split into pieces inside a package or die.  Logical nodes may match
die boundaries, or there may be multiple logical nodes within a single
physical package or die.

We have mechanisms for explicitly enumerating the caches,
and for nodes.  This patch series does not touch those mechanisms.

The reason we need to know about physical packages and die is that
there are other things associated with them.
eg. power and temperature domains, and certain system registers
follow these physical boundaries.  Code that talks to those items
needs to be able to understand these physical boundaries.

I hope that helps.

thanks,
Len Brown, Intel Open Source Technology Center