Re: [PATCH] mm/page_owner.c: allow page_owner with given start_pfn/count

[Kassey Li]

On 7/27/2022 6:59 PM, Vlastimil Babka (SUSE) wrote:
> On 7/27/22 09:44, Kassey Li wrote:
> > On 7/26/2022 10:03 PM, Vlastimil Babka (SUSE) wrote:
> > > On 7/25/22 10:39, Kassey Li wrote:
> > > > hi, Matthew:
> > > >       sorry for the delay, I just started to learn how to upstream patch, and
> > > > setup my Thunderbird with plain text only.
> > > >       you are right, two users will cause problem here.
> > > >       the uses case is dump CMA area to understand the page usage in a given
> > > > cma pool. 2nd, dump whole memory page owner is very time cost, mostly our
> > > > android device has 8G memory now.
> > > >       I will research and check again, if you have more idea on this , please
> > > > kindly to share.
> > >
> > > You could try employing lseek() to specify the start pfn, and as for end
> > > pfn, the process can just stop reading and close when it has seen enough?
> >
> > lseek is a good idea.
> > read_page_owner start with below
> >      pfn = min_low_pfn + *ppos;
> > so we need to export the min_low_pfn to user then decide the ppos to seek.
> > (my_cma.base_pfn - min_low_pfn) is the ppos we want to set.
>
> Hm could we just pfn = *ppos and then anything below min_low_pfn is skipped
> internally? So we don't need to teach userspace min_low_pfn.
	that makes sense.
	I send out a new path "mm/page_owner.c: add llseek for page_owner" 
according your suggest, please help to review again, thanks.
> > is there concern to export min_low_pfn  ?
> > or use a mutex lock for my previous debugfs version patch ?
> >
> > > > BR
> > > > Kassey
> > > >
> > > > On 7/22/2022 11:38 PM, Matthew Wilcox wrote:
> > > > > On Fri, Jul 22, 2022 at 11:08:10PM +0800, Kassey Li wrote:
> > > > > > by default, page_owner iterates all page from min_low_pfn to
> > > > > > max_pfn, this cost too much time if we want an alternative pfn range.
> > > > > >
> > > > > > with this patch it allows user to set pfn range to dump the page_onwer.
> > > > >
> > > > > This is a really bad UI.  If two users try to do different ranges at the
> > > > > same time, it'll go wrong.  What use cases are you actually trying to
> > > > > solve?