On 14/03/18 19:33, Matthew Wilcox wrote: > I think an implementation of > pmalloc which used a page_frag-style allocator would be larger than > 100 lines, but I don't think it would have to be significantly larger > than that. I have some doubt about what is the best way to implement it using vmalloced memory. 1. Since I can allocate an arbitrary number of pages, I think allocating a rounded up amount of memory, so that it's multiple of PAGE_SIZE should be enough. But maybe I could do better than that: a) support pre-allocation of x pages b) define, as pool parameter, the minimum number of pages to allocate every time there is a refill c) both a and b ---- 2. the flavor of page_frag from page_alloc relies on page->_refcount, however neither vmap_area, nor vm_struct seem to have anything like that. (My reasoning is that I should do the accounting not on page level, but based on the virtual area that I get when I allocate new memory) What would be the best way to do refcounting for the area? a) use the the page->_refcount from the first page that belongs to the area b) add the _refcount to either vm_struct or vmap_area (I am not really sure of why these two structures exist as separate entities, rather than a single one - cache optimization?) ---- 3. I will have to add a list of chunks (in genalloc lingo, or areas, if we refer to the new implementation), because I will still need to iterate over all the memory that belongs to a pool, for either write protecting it or for destroying the pool. I have two options: a) handle the chunks within the pmalloc pool b) create an intermediate type of pool (vfrag_pool?) and then include it in the pmalloc pool structure. I'd lean toward option a, but I thought I might as well ask for advice before I implement the less desirable option (whatever it might be). -- thanks, igor
