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. > For KSM, that would mean that you have a folio+page (late folio+index) pair > when possibly dealing with large folios, but you can use a folio without a > page when dealing with KSM folios, that are always small. Yes, agreed.
