Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <bfcddb31-b721-a080-a9b6-161f1d1c674b@quicinc.com>
Date:   Wed, 27 Jul 2022 20:58:35 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.0.3
Subject: Re: [PATCH] mm/page_owner.c: allow page_owner with given
 start_pfn/count
To:     "Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
        Matthew Wilcox <willy@infradead.org>
CC:     <akpm@linux-foundation.org>, <minchan@kernel.org>,
        <iamjoonsoo.kim@lge.com>, <linux-kernel@vger.kernel.org>,
        <linux-mm@kvack.org>, <quic_guptap@quicinc.com>,
        <quic_zhenhuah@quicinc.com>
References: <20220722150810.27740-1-quic_yingangl@quicinc.com>
 <YtrEXB6o+VROImdg@casper.infradead.org>
 <e518246c-4ffa-14af-e568-798572f75bee@quicinc.com>
 <ce6f3bcf-fe77-d042-4517-dd09d090b70b@kernel.org>
 <b2814a36-4021-b2a4-52db-6ac707d32835@quicinc.com>
 <ef94e33b-a006-ab3c-b6f9-e567220eb94c@kernel.org>
Content-Language: en-US
From:   Kassey Li <quic_yingangl@quicinc.com>
In-Reply-To: <ef94e33b-a006-ab3c-b6f9-e567220eb94c@kernel.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


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?
>>>>
>>>
>