Re: [PATCH] perf: map pages in advance

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

 



On Fri, Nov 29, 2024 at 01:45:42PM +0100, David Hildenbrand wrote:
> On 29.11.24 13:26, Peter Zijlstra wrote:
> > On Fri, Nov 29, 2024 at 01:12:57PM +0100, David Hildenbrand wrote:
> >
> > > Well, I think we simply will want vm_insert_pages_prot() that stops treating
> > > these things like folios :) . *likely*  we'd want a distinct memdesc/type.
> > >
> > > We could start that work right now by making some user (iouring,
> > > ring_buffer) set a new page->_type, and checking that in
> > > vm_insert_pages_prot() + vm_normal_page(). If set, don't touch the refcount
> > > and the mapcount.
> > >
> > > Because then, we can just make all the relevant drivers set the type, refuse
> > > in vm_insert_pages_prot() anything that doesn't have the type set, and
> > > refuse in vm_normal_page() any pages with this memdesc.
> > >
> > > Maybe we'd have to teach CoW to copy from such pages, maybe not. GUP of
> > > these things will stop working, I hope that is not a problem.
> >
> > Well... perf-tool likes to call write() upon these pages in order to
> > write out the data from the mmap() into a file.

I'm confused about what you mean, write() using the fd should work fine, how
would they interact with the mmap? I mean be making a silly mistake here

>
> I think a PFNMAP as used in this patch here will already stop making that
> work ....

Actually I think GUP should work fine, except if you explicitly use a version
that expects an array of struct page *'s, because obviously those can't be
provided?

>
> --
> Cheers,
>
> David / dhildenb
>




[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