All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Jinhui Guo <guojinhui.liam@bytedance.com>,
	<linux-kernel@vger.kernel.org>
Cc: <catalin.marinas@arm.com>, <linux-arm-kernel@lists.infradead.org>,
	<lizefan.x@bytedance.com>, <robin.murphy@arm.com>,
	<will@kernel.org>
Subject: Re: [PATCH] arm64: cpufeature: Expose the real mpidr value to EL0
Date: Wed, 13 Sep 2023 14:11:36 +0100	[thread overview]
Message-ID: <20230913141136.00006a47@Huawei.com> (raw)
In-Reply-To: <20230913105133.2902-1-guojinhui.liam@bytedance.com>

On Wed, 13 Sep 2023 18:51:33 +0800
Jinhui Guo <guojinhui.liam@bytedance.com> wrote:

> > As a follow up question, is there some information that is missing from
> > current topology description?  (there is lots missing but I'm curious
> > as to what might matter for your use case!)  
> 
> We want to know the infomation about dies to advoid memroy accessing
> across dies (some settings like 2 numa per die).

The NUMA access characteristics should give you the info you want - it's
the variation in latency and bandwidth between dies that matters, not that
they are dies.  If you got really bad access characteristics across a die
that info would be equally useful.

I think it is not that this is a die that matters, but rather that there
are groups of Numa nodes with relatively small differences in access
characteristics, then others with much larger variation (and I assume
a layer above that which is inter socket which is even worse).

The info is in HMAT, but the kernel presentation of HMAT is rather limited
currently - so you may want to look at extending what is visible in sysfs
from that table.

Thanks,

Jonathan

> 
> thanks,
> 
> Jinhui Guo
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Jinhui Guo <guojinhui.liam@bytedance.com>,
	<linux-kernel@vger.kernel.org>
Cc: <catalin.marinas@arm.com>, <linux-arm-kernel@lists.infradead.org>,
	<lizefan.x@bytedance.com>, <robin.murphy@arm.com>,
	<will@kernel.org>
Subject: Re: [PATCH] arm64: cpufeature: Expose the real mpidr value to EL0
Date: Wed, 13 Sep 2023 14:11:36 +0100	[thread overview]
Message-ID: <20230913141136.00006a47@Huawei.com> (raw)
In-Reply-To: <20230913105133.2902-1-guojinhui.liam@bytedance.com>

On Wed, 13 Sep 2023 18:51:33 +0800
Jinhui Guo <guojinhui.liam@bytedance.com> wrote:

> > As a follow up question, is there some information that is missing from
> > current topology description?  (there is lots missing but I'm curious
> > as to what might matter for your use case!)  
> 
> We want to know the infomation about dies to advoid memroy accessing
> across dies (some settings like 2 numa per die).

The NUMA access characteristics should give you the info you want - it's
the variation in latency and bandwidth between dies that matters, not that
they are dies.  If you got really bad access characteristics across a die
that info would be equally useful.

I think it is not that this is a die that matters, but rather that there
are groups of Numa nodes with relatively small differences in access
characteristics, then others with much larger variation (and I assume
a layer above that which is inter socket which is even worse).

The info is in HMAT, but the kernel presentation of HMAT is rather limited
currently - so you may want to look at extending what is visible in sysfs
from that table.

Thanks,

Jonathan

> 
> thanks,
> 
> Jinhui Guo
> 


  reply	other threads:[~2023-09-13 13:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12  3:52 [PATCH] arm64: cpufeature: Expose the real mpidr value to EL0 guojinhui.liam
2023-09-12  3:52 ` guojinhui.liam
2023-09-12  8:31 ` Robin Murphy
2023-09-12  8:31   ` Robin Murphy
2023-09-12 10:51   ` Jonathan Cameron
2023-09-13 10:51     ` Jinhui Guo
2023-09-13 10:51       ` Jinhui Guo
2023-09-13 13:11       ` Jonathan Cameron [this message]
2023-09-13 13:11         ` Jonathan Cameron
2023-09-13  9:44   ` guojinhui
2023-09-13  9:44     ` guojinhui
2023-09-13 11:23     ` Robin Murphy
2023-09-13 11:23       ` Robin Murphy
2023-09-13 13:06       ` Jonathan Cameron
2023-09-13 13:06         ` Jonathan Cameron
2023-09-13 18:57         ` Robin Murphy
2023-09-13 18:57           ` Robin Murphy

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=20230913141136.00006a47@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=catalin.marinas@arm.com \
    --cc=guojinhui.liam@bytedance.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan.x@bytedance.com \
    --cc=robin.murphy@arm.com \
    --cc=will@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.