Michael Kelley [off-list ref] writes:
From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Wednesday, May 8, 2019 7:55 AM
quoted
quoted
quoted
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