On 8/15/24 11:13 AM, Sergey Senozhatsky wrote: > On (24/08/09 10:32), Alex Shi wrote: > [..] >>>> 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. >> >> Thanks for the suggestions! Yes, it's a good direction we could try after this >> patchset. > > Alex, may I ask what exactly you will "try"? Hi Sergey, Thanks for question. As a quick amateur thought, the final result may like following, please correct me if I am wrong. 1, there is a memdesc for each of memory page. 2, we kmem_alloc some zpdesc struct for specifically our needs, like zpdesc.next zpdesc.zspage/first_obj_offset, these current we used in zsmalloc. 3, there is a gap between memdesc and zpdesc, like .flags, _refcount, .mops etc. this part is still unclear that how to handle them well. During the 2nd, 3rd steps, we may have chance to move some members from zpdesc, to zspage? but it's also unclear. Thanks Alex
