From: Eli Billauer <eli.billauer@gmail.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: David Laight <david.laight.linux@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
Brad Warrum <bwarrum@linux.ibm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Michal Simek <michal.simek@amd.com>,
Ritu Agarwal <rituagar@linux.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/4] char: xillybus: replace __get_free_pages() with kmalloc()
Date: Wed, 2 Sep 2026 13:41:54 +0200 [thread overview]
Message-ID: <9a3d6a08-339c-3315-cc81-46907d0836ad@outbound.gmail.com> (raw)
In-Reply-To: <apcPg_y-HsMki7we@kernel.org>
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.
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
next prev parent reply other threads:[~2026-09-02 11:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 7:47 [PATCH 0/4] char/misc: replace page allocator calls with k[mz]alloc() Mike Rapoport (Microsoft)
2026-08-30 7:47 ` [PATCH 1/4] char: xilinx_hwicap: " Mike Rapoport (Microsoft)
2026-08-30 7:47 ` [PATCH 2/4] char: xillybus: replace __get_free_pages() with kmalloc() Mike Rapoport (Microsoft)
2026-08-31 10:13 ` Eli Billauer
2026-08-31 11:32 ` Mike Rapoport
2026-09-01 8:42 ` Eli Billauer
2026-09-01 17:24 ` Mike Rapoport
2026-09-02 11:40 ` Eli Billauer
2026-09-03 9:15 ` Mike Rapoport
2026-08-31 11:39 ` David Laight
2026-09-01 7:59 ` Mike Rapoport
2026-09-01 8:37 ` David Laight
2026-09-01 8:44 ` Eli Billauer
2026-09-01 17:46 ` Mike Rapoport
2026-09-02 11:41 ` Eli Billauer [this message]
2026-09-02 12:09 ` Mike Rapoport
2026-09-03 12:30 ` Eli Billauer
2026-09-02 12:25 ` Pedro Falcato
2026-09-02 12:26 ` David Laight
2026-08-30 7:48 ` [PATCH 3/4] misc: ibmvmc: replace get_zeroed_page() with kzalloc() Mike Rapoport (Microsoft)
2026-08-30 7:48 ` [PATCH 4/4] platform: goldfish: pipe: replace __get_free_page() with kmalloc() Mike Rapoport (Microsoft)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a3d6a08-339c-3315-cc81-46907d0836ad@outbound.gmail.com \
--to=eli.billauer@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bwarrum@linux.ibm.com \
--cc=david.laight.linux@gmail.com \
--cc=david@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=michal.simek@amd.com \
--cc=rituagar@linux.ibm.com \
--cc=rppt@kernel.org \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox