All of lore.kernel.org
 help / color / mirror / Atom feed
From: haoxin <xhao@linux.alibaba.com>
To: David Hildenbrand <david@redhat.com>, willy@infradead.org
Cc: akpm@linux-foundation.org, adobriyan@gmail.com,
	keescook@chromium.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [RFC PATCH V4 1/1] mm: add last level page table numa info to /proc/pid/numa_pgtable
Date: Thu, 4 Aug 2022 17:30:33 +0800	[thread overview]
Message-ID: <a0e46572-5b37-7bb3-20f0-740a6480e50e@linux.alibaba.com> (raw)
In-Reply-To: <eaaab6c4-1719-5e21-ebf7-a0c17487314c@redhat.com>


在 2022/8/4 下午4:12, David Hildenbrand 写道:
> On 04.08.22 10:04, haoxin wrote:
>> 在 2022/8/1 下午9:28, David Hildenbrand 写道:
>>> On 01.08.22 14:17, Xin Hao wrote:
>>>> In many data center servers, the shared memory architectures is
>>>> Non-Uniform Memory Access (NUMA), remote numa node data access
>>>> often brings a high latency problem, but what we are easy to ignore
>>>> is that the page table remote numa access, It can also leads to a
>>>> performance degradation.
>>> Let me try rewriting:
>>>
>>> "
>>> Many data center servers employ Non-Uniform Memory Access (NUMA)
>>> architectures. Remote numa memory access results in high latency. While
>>> memory placement is one issue, sub-optimal page table placement can also
>>> result in surprise performance degradation.
>>> "
>> Thanks,  it reads more clearly.
>>
>>>> So there add a new interface in /proc, This will help developers to
>>>> get more info about performance issues if they are caused by cross-NUMA.
>>> Why do we only care about "last level page table", why not about the others?
>>>
>>> IMHO, we could emit something like "0, 1, 3, 0" instead for a given user
>>> space address, showing the NUMA node the page table belongs to from
>>> highest to lowest page table level.
>> I have planned to implement the PTE page table in this version first,
>> and then support other page tables in the next patch later.
> If there are plans, let's do it all at once, to get a good and single
> interface to expose that information.
Ok, thanks for your suggestion, I will implement it in the next version.

>


      reply	other threads:[~2022-08-04  9:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01 12:17 [RFC PATCH V4 0/1] mm: add last level page table numa info to /proc/pid/numa_pgtable Xin Hao
2022-08-01 12:17 ` [RFC PATCH V4 1/1] " Xin Hao
2022-08-01 13:28   ` David Hildenbrand
2022-08-04  8:04     ` haoxin
2022-08-04  8:12       ` David Hildenbrand
2022-08-04  9:30         ` haoxin [this message]

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=a0e46572-5b37-7bb3-20f0-740a6480e50e@linux.alibaba.com \
    --to=xhao@linux.alibaba.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.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.