On 4/2/25 13:13, Jaco Kroon wrote: > Hi, > > On 2025/04/02 11:10, Bernd Schubert wrote: >> >> On 4/2/25 10:52, Jaco Kroon wrote: >>> Hi, >>> >>> On 2025/04/02 10:18, Miklos Szeredi wrote: >>>> On Wed, 2 Apr 2025 at 09:55, Jaco Kroon <jaco@xxxxxxxxx> wrote: >>>>> Hi, >>>>> >>>>> I can definitely build on that, thank you. >>>>> >>>>> What's the advantage of kvmalloc over folio's here, why should it be >>>>> preferred? >>>> It offers the best of both worlds: first tries plain malloc (which >>>> just does a folio alloc internally for size > PAGE_SIZE) and if that >>>> fails, falls back to vmalloc, which should always succeed since it >>>> uses order 0 pages. >>> So basically assigns the space, but doesn't commit physical pages for >>> the allocation, meaning first access will cause a page fault, and single >>> page allocation at that point in time? Or is it merely the fact that >>> vmalloc may return a virtual contiguous block that's not physically >>> contiguous? >> >> Yes vmalloc return buffers might not be physically contiguous - not >> suitable for hardware DMA. And AFAIK it is also a blocking allocation. > How do I go about confirming? Can that behaviour be stopped so that in > the case where it would block we can return an EAGAIN or EWOULDBLOCK > error code instead? Is that even desired? > > Don't think hardware DMA is an issue here, so that's at least not an > issue, but the blocking might be? I was just writing what vmalloc does - neither of its disadvantages will have an issue here
