On 02/09/2026 14:09, Mike Rapoport wrote:
So using vmalloc() may result in a malfunction in the data transport where
the __get_free_pages() would have been successful. This outweighs the
benefit of a somewhat higher probability of success in allocating very large
buffers, and surely the improved aesthetics of the kernel code.
kmalloc() still works, just like __get_free_pages()
After these few days of discussion, this is what I make of this topic.
The memory allocation in fifo_init() is somewhat ugly, but this driver
has been out there for five years, and no complaints from users.
The vmalloc() option may be successful sometimes where the current
allocation will not. On the other hand, there is a possibility that it
will cause real trouble with page faults. Plus, a large allocation with
vmalloc() may be a weak spot on a platform to which the kernel is
partially or poorly ported.
With __get_free_pages(), there is no doubt that usable memory is
allocated right away, and that it will work that way on every single
esoteric platform. vmalloc() leaves us with "we're pretty sure there is
probably no problem".
So I vote against vmalloc().
As for replacing __get_free_pages() with kmalloc(), it's a matter of
taste. I think that if you're after a buffer that has a power-of-two
number of pages, __get_free_pages() is the natural choice, and using it
makes it easier for the reader to understand what you're doing.
Replacing it with a kmalloc() is confusing in my opinion, and requires
that the reader is aware that kmalloc() falls back to __get_free_pages()
in this case. So we actually want __get_free_pages(), but call kmalloc()
instead and let it fall back to __get_free_pages() so we don't have a
cast and don't need to save the order, and assume that everyone knows
that this is equivalent.
So I vote against the kmalloc() thing as well.
If this patch is part of a larger kernel cleanup, I suppose my votes
don't count for much. But for the record, this is my opinion.
Thanks and regards,
Eli
