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 Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux