All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shijie Huang <shijie@amperemail.onmicrosoft.com>
To: torvalds@linux-foundation.org, viro@zeniv.linux.org.uk,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	song.bao.hua@hisilicon.com
Cc: linux-kernel@vger.kernel.org, Frank Wang <zwang@amperecomputing.com>
Subject: Is it possible to implement the per-node page cache for programs/libraries?
Date: Wed, 1 Sep 2021 11:07:41 +0800	[thread overview]
Message-ID: <a2f423cf-9413-6bc8-e4d8-92374fc0449e@amperemail.onmicrosoft.com> (raw)

Hi Everyone,

     In the NUMA, we only have one page cache for each file. For the 
program/shared libraries, the

remote-access delays longer then the  local-access.

So, is it possible to implement the per-node page cache for 
programs/libraries?


    We can do it like this:

         1.) Add a new system call to control specific files to 
NUMA-aware, such as:

                    set_numa_aware("/usr/lib/libc.so", enable);

             After the system call, the page cache of libc.so has the 
flags "NUMA_ENABLED"


         2.) When A new process tries to setup the MMU page table for 
libc.so, it will check

              if NUMA_ENABLED is set. If it set, the kernel will give a 
page which is bind to the process's NUMA node.

              By this way, we can eliminate the remote-access for 
programs/shared library.


Is this proposal ok?  Or do you have a better idea?


Thanks

Huang Shijie







WARNING: multiple messages have this Message-ID (diff)
From: Shijie Huang <shijie@amperemail.onmicrosoft.com>
To: torvalds@linux-foundation.org, viro@zeniv.linux.org.uk,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	song.bao.hua@hisilicon.com
Cc: linux-kernel@vger.kernel.org, Frank Wang <zwang@amperecomputing.com>
Subject: Is it possible to implement the per-node page cache for programs/libraries?
Date: Wed, 1 Sep 2021 11:07:41 +0800	[thread overview]
Message-ID: <a2f423cf-9413-6bc8-e4d8-92374fc0449e@amperemail.onmicrosoft.com> (raw)

Hi Everyone,

     In the NUMA, we only have one page cache for each file. For the
program/shared libraries, the

remote-access delays longer then the  local-access.

So, is it possible to implement the per-node page cache for
programs/libraries?


    We can do it like this:

         1.) Add a new system call to control specific files to
NUMA-aware, such as:

                    set_numa_aware("/usr/lib/libc.so", enable);

             After the system call, the page cache of libc.so has the
flags "NUMA_ENABLED"


         2.) When A new process tries to setup the MMU page table for
libc.so, it will check

              if NUMA_ENABLED is set. If it set, the kernel will give a
page which is bind to the process's NUMA node.

              By this way, we can eliminate the remote-access for
programs/shared library.


Is this proposal ok?  Or do you have a better idea?


Thanks

Huang Shijie








CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any unauthorized review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


             reply	other threads:[~2021-09-01  3:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01  3:07 Shijie Huang [this message]
2021-09-01  3:07 ` Is it possible to implement the per-node page cache for programs/libraries? Shijie Huang
2021-09-01  2:09 ` Barry Song
2021-09-01  2:09   ` Barry Song
2021-09-01  3:25 ` Matthew Wilcox
2021-09-01 13:30   ` Huang Shijie
2021-09-01 14:25     ` Huang Shijie
2021-09-01 11:32       ` Matthew Wilcox
2021-09-01 23:58       ` Matthew Wilcox
2021-09-02  0:15         ` Barry Song
2021-09-02  0:15           ` Barry Song
2021-09-02  1:13           ` Linus Torvalds
2021-09-02  1:13             ` Linus Torvalds
2021-09-02 10:16         ` Huang Shijie
2021-09-02  3:25   ` Nicholas Piggin
2021-09-02 10:17     ` Matthew Wilcox
2021-09-03  7:10       ` Nicholas Piggin
2021-09-03 19:01         ` Matthew Wilcox
2021-09-03 19:08           ` Linus Torvalds
2021-09-03 19:08             ` Linus Torvalds
2021-09-06  9:56             ` Huang Shijie
2021-09-03 23:42           ` Nicholas Piggin
2021-09-01  4:55 ` Al Viro
2021-09-01 13:10   ` Huang Shijie
2021-09-01 17:24   ` Linus Torvalds
2021-09-01 17:24     ` Linus Torvalds
2021-09-01 17:29     ` Linus Torvalds
2021-09-01 17:29       ` Linus Torvalds
2021-09-01 22:56       ` Barry Song
2021-09-01 22:56         ` Barry Song
2021-09-02 10:12         ` Huang Shijie
2021-09-02 10:08       ` Huang Shijie

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=a2f423cf-9413-6bc8-e4d8-92374fc0449e@amperemail.onmicrosoft.com \
    --to=shijie@amperemail.onmicrosoft.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=song.bao.hua@hisilicon.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zwang@amperecomputing.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 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.