Hi Pratyush, On Wed, Sep 03, 2025 at 04:17:15PM +0200, Pratyush Yadav wrote: > On Tue, Sep 02 2025, Mike Rapoport wrote: > > > > As for porting kho_preserve_vmalloc() to kho_array, I also feel that it > > would just make kho_preserve_vmalloc() more complex and I'd rather simplify > > it even more, e.g. with preallocating all the pages that preserve indices > > in advance. > > I think there are two parts here. One is the data format of the KHO > array and the other is the way to build it. I think the format is quite > simple and versatile, and we can have many strategies of building it. > > For example, if you are only concerned with pre-allocating data, I can > very well add a way to initialize the KHO array with with a fixed size > up front. I wasn't concerned with preallocation vs allocating a page at a time, I though with preallocation the vmalloc code will become even simpler, but it's not :) > Beyond that, I think KHO array will actually make kho_preserve_vmalloc() > simpler since it won't have to deal with the linked list traversal > logic. It can just do ka_for_each() and just get all the pages. > > We can also convert the preservation bitmaps to use it so the linked list > logic is in one place, and others just build on top of it. I disagree. The boilerplate to initialize and iterate the kho_array will not make neither vmalloc nor bitmaps preservation simpler IMO. And for bitmaps Pasha and Jason M. are anyway working on a different data structure already, so if their proposal moves forward converting bitmap preservation to anything would be a wasted effort. > -- > Regards, > Pratyush Yadav -- Sincerely yours, Mike.
