On 05.06.24 23:12, Matthew Wilcox wrote:
On Wed, Jun 05, 2024 at 09:47:10AM +0200, David Hildenbrand wrote:
On 05.06.24 08:14, Alex Shi wrote:
On 6/5/24 11:52 AM, Matthew Wilcox wrote:
On Tue, Jun 04, 2024 at 12:24:44PM +0800, alexs@xxxxxxxxxx wrote:
From: "Alex Shi (tencent)" <alexs@xxxxxxxxxx>
When a folio isn't fit for KSM, the subpages are unlikely to be good,
So let's skip the rest page checking to save some actions.
Why would you say that is true? We have plenty of evidence that
userspace allocators can allocate large folios, then use only the first
few bytes, leaving many tail pages full of zeroes.
Um, that do need tail pages...
Is there some way to use more folio in ksm?
My take, and Willy can correct me if I am wrong:
"struct page" is not going to away any time soon, but it might shrink at
some point.
That is, we can use the "struct page" pointer to point at a page frame, and
use "struct folio" to lookup/manage the metadata.
Right.
That is, use "struct page" when accessing the actual memory content
(checksum, testing for identical content), but use the folio part when
looking up metadata (folio_test_anon() etc). In the future we might want to
replace the "struct page" pointer by an index into the folio, but that
doesn't have to happen right now.
My current thinking is that folio->pfn is how we know where the memory
described by the folio is. Using an index would be memmap[folio->pfn +
index] which isn't terribly expensive, but we may as well pass around the
(folio, page) pair and save the reference to memmap.
Right, as soon as the folio does not overlay the head page it's going to
be a bit different.
A (folio,page) pair, like we use in the RMAP code, is likely the best
option for now and gives us sufficient flexibility for the future design.
--
Cheers,
David / dhildenb
