On 01/09/2026 9:59, Mike Rapoport wrote:
Would it really make sense to allocate the four buffers separately?
And/or use vmalloc().
My understanding is that the buffers don't need to be physically
contiguous and vmalloc()ing the entire fifo->mem in one go should work.

vmalloc() is an interesting point.

fifo_init(), fifo_write(), fifo_read() and fifo_mem_release() implement a FIFO in software that the XillyUSB driver uses internally.

The memory for this FIFO is allocated in fifo_init() by calling __get_free_pages() with requests for up to 64 kiB. With the maximal total buffer size of 256 MiB, we have a possibility of 4096 allocations into an array of buffers. And if __get_free_pages() fails, the size of each buffer is halved in the following attempt, which tries to allocate 8192 buffers, each 32 kiB, in this example. And so on.

This mechanism with an array of buffers complicates the implementation of the other functions as well.

So why not replace this with a single call to vmalloc(), possibly asking for 256 MiB in one call? That would mean simplifying all four functions.

When I wrote this driver back in 2020, I avoided vmalloc() because Linus wrote "vmalloc() is NOT SOMETHING YOU SHOULD EVER USE!". (See [1]). He also noted that vmalloc() is a restricted resource. But that's from 2003, so maybe things have changed since?

Questions that arise in this context:

* Does vmalloc() guarantee that non-pageable physical RAM is allocated when it returns?
* Can copy_to/from_user() be used with memory allocated with vmalloc().
* Is vmalloc() guaranteed to successfully allocate memory in the same situation that __get_free_pages() could have been used to obtain the same amount of memory (in smaller chunks, as with fifo_init() )? Maybe they allocate memory from separate memory pools?

And most important: In what way, if at all, is memory obtained with vmalloc() practically different from memory allocated by __get_free_pages(), if it's never used for DMA?

Does the API offer clear answers to these questions?

Thanks in advance,
   Eli

[1] https://lwn.net/Articles/57804/

Reply via email to