On Wed, Aug 07, 2024 at 02:17:54PM +0900, Sergey Senozhatsky wrote: > On (24/08/06 12:34), Yosry Ahmed wrote: > [..] > > > So the sole reason for this work is as a part of the mem_desc > > > conversion. I'd like to hear from others who are to be involved in > > > that conversion, please - it this patchset something we should be > > > merging? > > > > > > > Matthew asked an important question here that needs to be answered by > > zsmalloc experts: > > https://lore.kernel.org/lkml/Zq0zucMFsOwATsAC@xxxxxxxxxxxxxxxxxxxx/ > > Iff "zsmalloc experts" include me: I was under impression that there was > a zsmalloc conversion plan otherwise this zpdesc effort is a little > confusing, and, frankly, it hasn't appeared to me that this is "my problem" > now. I don't know if it's _your_ problem. It's _our_ problem. The arguments for (at least attempting) to shrink struct page seem quite compelling. We have a plan for most of the users of struct page, in greater or lesser detail. I don't think we have a plan for zsmalloc. Or at least if there is a plan, I don't know what it is. > > Do you allocate a per-page struct zpdesc, and have each one pointing > > to a zspage? > > I'm not very knowledgeable when it comes to memdesc, excuse my > ignorance, and please feel free to educate me. I've written about it here: https://kernelnewbies.org/MatthewWilcox/Memdescs https://kernelnewbies.org/MatthewWilcox/FolioAlloc https://kernelnewbies.org/MatthewWilcox/Memdescs/Path > So I guess if we have something > > struct zspage { > .. > struct zpdesc *first_desc; > .. > } > > and we "chain" zpdesc-s to form a zspage, and make each of them point to > a corresponding struct page (memdesc -> *page), then it'll resemble current > zsmalloc and should work for everyone? I also assume for zspdesc-s zsmalloc > will need to maintain a dedicated kmem_cache? Right, we could do that. Each memdesc has to be a multiple of 16 bytes, sp we'd be doing something like allocating 32 bytes for each page. Is there really 32 bytes of information that we want to store for each page? Or could we store all of the information in (a somewhat larger) zspage? Assuming we allocate 3 pages per zspage, if we allocate an extra 64 bytes in the zspage, we've saved 32 bytes per zspage.
