Michael Kelley <mikelley@xxxxxxxxxxxxx> writes: > From: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> Sent: Wednesday, May 8, 2019 7:55 AM >> >> >> >> Sorry, my bad: I meant to say "not cache-like" (these allocations are >> >> not 'cache') but the typo made it completely incomprehensible. >> > >> > No worries! Thank you for sharing your thoughts with me, Vitaly. >> > >> > Do you know of any alternatives to kmem_cache that can allocate memory >> > in a specified size (different than a guest page size) with alignment? >> > Memory allocated by alloc_page() is aligned but limited to the guest >> > page size, and kmalloc() can allocate a particular size but it seems >> > that it does not guarantee alignment. I am asking this while considering >> > the changes for architecture independent code. >> > >> >> I think we can consider these allocations being DMA-like (because >> Hypervisor accesses this memory too) so you can probably take a look at >> dma_pool_create()/dma_pool_alloc() and friends. >> > > I've taken a look at dma_pool_create(), and it takes a "struct device" > argument with which the DMA pool will be associated. That probably > makes DMA pools a bad choice for this usage. Pages need to be allocated > pretty early during boot for Hyper-V communication, and even if the > device subsystem is initialized early enough to create a fake device, > such a dependency seems rather dubious. We can probably use dma_pool_create()/dma_pool_alloc() from vmbus module but these 'early' allocations may not have a device to bind to indeed. > > kmem_cache_create/alloc() seems like the only choice to get > guaranteed alignment. Do you see any actual problem with > using kmem_cache_*, other than the naming? It seems like these > kmem_cache_* functions really just act as a sub-allocator for > known-size allocations, and "cache" is a common usage > pattern, but not necessarily the only usage pattern. Yes, it's basically the name - it makes it harder to read the code and some future refactoring of kmem_cache_* may not take our use-case into account (as we're misusing the API). We can try renaming it to something generic of course and see what -mm people have to say :-) -- Vitaly
