From: Huang Shijie <email@example.com> To: Matthew Wilcox <firstname.lastname@example.org> Cc: Shijie Huang <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Frank Wang <firstname.lastname@example.org> Subject: Re: Is it possible to implement the per-node page cache for programs/libraries? Date: Wed, 1 Sep 2021 13:30:45 +0000 [thread overview] Message-ID: <YS+AhXJGsniaHTS4@hsj> (raw) In-Reply-To: <YS7yjcqA6txFHd99@casper.infradead.org> On Wed, Sep 01, 2021 at 04:25:01AM +0100, Matthew Wilcox wrote: > On Wed, Sep 01, 2021 at 11:07:41AM +0800, Shijie Huang wrote: > > 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? > > At this point, we have no way to support text replication within a > process. So what you're suggesting (if implemented) would work for I created a glibc patch which can do the text replication within a process. I will send to glibc maintainer later.. (it seems glibc does not use patches to maintain the code.) > processes which limit themselves to a single node. That is, if you > have a system with CPUs 0-3 on node 0 and CPUs 4-7 on node 1, a process > which only works on node 0 or only works on node 1 will get text on the > appropriate node. > > If there's a process which runs on both nodes 0 and 1, there's no support > for per-node PGDs. So it will get a mix of pages from nodes 0 and 1, I think we do not need the per-node PGDs. One-PGD for one process is okay to me. > and that doesn't necessarily seem like a big win. I haven't yet dived > into how hard it would be to make mm->pgd a per-node allocation. > > I have been thinking about this a bit; one of our internal performance > teams flagged the potential performance win to me a few months ago. > I don't have a concrete design for text replication yet; there have been > various attempts over the years, but none were particularly compelling. > > By the way, the degree of performance win varies between different CPUs, > but it's measurable on all the systems we've tested on (from three > different vendors). Thank you for sharing this. Thanks Huang Shijie
next prev parent reply other threads:[~2021-09-01 5:32 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-01 3:07 Shijie Huang 2021-09-01 3:07 ` 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 [this message] 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=YS+AhXJGsniaHTS4@hsj \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Is it possible to implement the per-node page cache for programs/libraries?' \ /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
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.