On 8/7/24 1:17 PM, 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. > >> 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. > > 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? Yes, it would be a better way moving to memdesc, and using kmem_cache for zpdesc-s seems workable. Thanks Alex
