Re: [RFC] vmap_folio()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 19, 2022 at 04:45:05PM +0100, Matthew Wilcox wrote:
> On Fri, Aug 19, 2022 at 12:53:32PM +0200, Uladzislau Rezki wrote:
> > Looks pretty straightforward. One thing though, if we can combine it
> > together with vmap(), since it is a copy paste in some sense, say to
> > have something __vmap() to reuse it in the vmap_folio() and vmap().
> > 
> > But that is just a thought.
> 
> Thanks for looking it over!
> 
You are welcome.

>
> Combining it with vmap() or vm_map_ram() is tricky.  Today, we assume
> that each struct page pointer refers to exactly PAGE_SIZE bytes, so if
> somebody calls alloc_pages(GFP_COMPOUND, 4) and then passes the head
> page to vmap(), only that one page gets mapped.  I don't know whether
> any current callers depend on that behaviour.
> 
> Now that I look at the future customers of this, I think I erred in basing
> this on vmap(), it looks like vm_map_ram() is preferred.  So I'll redo
> based on vm_map_ram().
> 
Indeed, the vmap code has no knowledge about comound pages. You can add
me to CC, so i can have a look on it to help out with it if there will
be a need.

--
Uladzislau Rezki




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux