From: David Rientjes <rientjes@google.com>
To: Matthew Wilcox <willy@infradead.org>,
Pasha Tatashin <tatashin@google.com>,
Sourav Panda <souravpanda@google.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-block@vger.kernel.org,
linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-nvme@lists.infradead.org, bpf@vger.kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] State Of The Page
Date: Sun, 21 Jan 2024 13:00:40 -0800 (PST) [thread overview]
Message-ID: <b04b65df-b25f-4457-8952-018dd4479651@google.com> (raw)
In-Reply-To: <ZaqiPSj1wMrTMdHa@casper.infradead.org>
On Fri, 19 Jan 2024, Matthew Wilcox wrote:
> It's probably worth doing another roundup of where we are on our journey
> to separating folios, slabs, pages, etc. Something suitable for people
> who aren't MM experts, and don't care about the details of how page
> allocation works. I can talk for hours about whatever people want to
> hear about but some ideas from me:
>
> - Overview of how the conversion is going
> - Convenience functions for filesystem writers
> - What's next?
> - What's the difference between &folio->page and page_folio(folio, 0)?
> - What are we going to do about bio_vecs?
> - How does all of this work with kmap()?
>
> I'm sure people would like to suggest other questions they have that
> aren't adequately answered already and might be of interest to a wider
> audience.
>
Thanks for proposing this again, Matthew, I'd definitely like to be
involved in the discussion as I think a couple of my colleagues, cc'd,
would has well. Memory efficiency is a top priority for 2024 and, thus,
getting on a pathway toward reducing the overhead of struct page is very
important for our hosts that are not using large amounts of 1GB hugetlb.
I've seen your other thread regarding how the page allocator can be
enlightened for memdesc, so I'm hoping that can either be covered in this
topic or a separate topic.
Especially important for us would be the division of work so that we can
parallelize development as much as possible for things like memdesc. If
there are any areas that just haven't been investigated yet but we *know*
we'll need to address to get to the new world of memdesc, I think we'd
love to discuss that.
next prev parent reply other threads:[~2024-01-21 21:00 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 16:24 Matthew Wilcox
2024-01-19 20:31 ` Keith Busch
2024-01-20 14:11 ` Chuck Lever III
2024-01-21 21:00 ` David Rientjes [this message]
2024-01-21 23:14 ` Matthew Wilcox
2024-01-21 23:31 ` Pasha Tatashin
2024-01-21 23:54 ` Matthew Wilcox
2024-01-22 0:18 ` Pasha Tatashin
2024-01-24 17:51 ` Christoph Lameter (Ampere)
2024-01-24 17:55 ` Matthew Wilcox
2024-01-24 19:05 ` Christoph Lameter (Ampere)
2024-01-27 10:10 ` Amir Goldstein
2024-01-27 16:18 ` Matthew Wilcox
2024-01-27 17:57 ` Kent Overstreet
2024-01-27 18:43 ` Matthew Wilcox
-- strict thread matches above, loose matches on Subject: below --
2023-01-26 16:40 Matthew Wilcox
2023-02-21 16:57 ` David Howells
2023-02-21 18:08 ` Gao Xiang
2023-02-21 19:09 ` Yang Shi
2023-02-22 2:40 ` Gao Xiang
2023-02-21 19:58 ` Matthew Wilcox
2023-02-22 2:38 ` Gao Xiang
2023-03-02 3:17 ` David Rientjes
2023-03-02 3:50 ` Pasha Tatashin
2023-03-02 4:03 ` Matthew Wilcox
2023-03-02 4:16 ` Pasha Tatashin
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=b04b65df-b25f-4457-8952-018dd4479651@google.com \
--to=rientjes@google.com \
--cc=bpf@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=souravpanda@google.com \
--cc=tatashin@google.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox