Re: [PATCH 2/4] char: xillybus: replace __get_free_pages() with kmalloc()

[David Laight <david.laight.linux@gmail.com>]

On Wed, 2 Sep 2026 13:41:54 +0200
Eli Billauer <eli.billauer@gmail.com> wrote:

> On 01/09/2026 19:46, Mike Rapoport wrote:
> >> * Does vmalloc() guarantee that non-pageable physical RAM is allocated when
> >> it returns?  
> > It's not pageable in the sense of demand paging. Some architectures lazily
> > synchronize vmalloc page tables and this can cause page faults that will
> > take care of the page table synchronization.
> >   
> 
> Thanks for this clarification.
> 
> This sounds like a showstopper to me. Immediately after the allocation 
> of these buffers, data from the USB device can arrive at 400 MB/s. If 
> the data flow is throttled as a result of handling page faults while 
> trying to write the data to these buffers, this could lead to an 
> overflow in the USB device's own RAM buffers. This is because the USB 
> device is an FPGA, where RAM is an expensive resource.

IIUC The faults don't usually happen.
But if one cpu write the address somewhere and another cpu picks it up
immediately and access the buffer you can get a fault.
Even if they do happen they are unlikely to be worse than normal
interrupt latency.

If you are trying to receive data at very high speed I'd have thought that
you'd want the USB data written directly into you buffer list.
(Much the same way as most ethernet hardware handles rx frames.)
I realise the the usb kernel code isn't really written for that sort
of access (some of usbnet could do with it).

David 

> 
> 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.
> 
> Regards,
>     Eli