[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZmiRcUYxrZ5NQQX8@casper.infradead.org>
Date: Tue, 11 Jun 2024 19:03:29 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Andrew Bresticker <abrestic@...osinc.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...hat.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm/memory: Don't require head page for do_set_pmd()
On Tue, Jun 11, 2024 at 08:32:16AM -0700, Andrew Bresticker wrote:
> - if (page != &folio->page || folio_order(folio) != HPAGE_PMD_ORDER)
> + if (folio_order(folio) != HPAGE_PMD_ORDER)
> return ret;
> + page = &folio->page;
This works today, but in about six months time it's going to be a pain.
+ page = folio_page(folio, 0);
is the one which works today and in the future.
Of course, as I'm writing this now I'm thinking we could make this work
for folios which are larger than PMD size. Which we currently prohibit
(at least in part because this function doesn't work with folios larger
than PMD size)
pgoff_t idx = ((haddr - vma->vm_start) / PAGE_SIZE) + vma->vm_pgoff;
page = folio_file_page(folio, idx);
(there might be a more succinct way to write that, and I might have
messed up the polarity on something).
Worth starting to fix these places that don't work with folios larger
than PMD size? I think it'd be worth supporting, eg 4MB folios.
Current bandwidth of a gen5 x8 link is 32GB/s, so we can read 8,000
4MB pages/second at a latency of 125us. My laptop only has a gen4 x2
SSD, so a 4MB folio would take 1ms to read which might be a little
excessive for normal use. Of course allocating an order 10 folio is
hard, so it's not going to happen terribly often anyway.
Powered by blists - more mailing lists