Messages in this thread | | | Date | Wed, 27 Jul 2022 20:58:35 +0800 | Subject | Re: [PATCH] mm/page_owner.c: allow page_owner with given start_pfn/count | From | 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? >>>> >>> >
| |