From: Nicholas Piggin <firstname.lastname@example.org> To: Matthew Wilcox <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Shijie Huang <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Frank Wang <email@example.com> Subject: Re: Is it possible to implement the per-node page cache for programs/libraries? Date: Sat, 04 Sep 2021 09:42:00 +1000 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <YTJxFgD0kKPs51dz@casper.infradead.org> Excerpts from Matthew Wilcox's message of September 4, 2021 5:01 am: > On Fri, Sep 03, 2021 at 05:10:31PM +1000, Nicholas Piggin wrote: >> Excerpts from Matthew Wilcox's message of September 2, 2021 8:17 pm: >> > On Thu, Sep 02, 2021 at 01:25:36PM +1000, Nicholas Piggin wrote: >> >> > 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. >> >> >> >> What was not compelling about it? >> > >> > It wasn't merged, so clearly it wasn't compelling enough? >> >> Ha ha. It sounded like you had some reasons you didn't find it >> particularly compelling :P > > I haven't studied it in detail, but it seems to me that your patch (from > 2007!) chooses whether to store pages or pcache_desc pointers in i_pages. > Was there a reason you chose to do it that way instead of having per-node > i_mapping pointers? What Linus said. The patch was obviously mechanism only and more heuristics would need to be done (in that case you could have per inode hints or whatever). > (And which way would you choose to do it now, given > the infrastructure we have now?) I'm not aware of anything new that would change it fundamentally. Thanks, Nick
next prev parent reply other threads:[~2021-09-03 23:42 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 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 [this message] 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 \ --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 \ --email@example.com \ --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.