From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67452C04A68 for ; Wed, 27 Jul 2022 12:58:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232825AbiG0M6p (ORCPT ); Wed, 27 Jul 2022 08:58:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231786AbiG0M6m (ORCPT ); Wed, 27 Jul 2022 08:58:42 -0400 Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA3472BB2F for ; Wed, 27 Jul 2022 05:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1658926721; x=1690462721; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=r+Snd/dR150rn/ALudIia+roqPZYxvTlnF6J8rxm1O4=; b=vJfCAtrGwxcBlRWS1q5ZUVW3AsFleIkJa0UHMxPbLDgByodLruCG6B1z tI0QYVCJlw1Hae+1q6uwLmfbiUdSTXMuudi0y+0SLHn0p7L8xa1sVHvE5 12baUf8gY2v2ivWfkjo5v1Y2GsOftSCWI1ho3gy4/ZSGFpeAHLs2g9+i0 Y=; Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30]) by alexa-out-sd-02.qualcomm.com with ESMTP; 27 Jul 2022 05:58:41 -0700 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jul 2022 05:58:41 -0700 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Wed, 27 Jul 2022 05:58:40 -0700 Received: from [10.232.65.248] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Wed, 27 Jul 2022 05:58:37 -0700 Message-ID: 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)" , Matthew Wilcox CC: , , , , , , References: <20220722150810.27740-1-quic_yingangl@quicinc.com> Content-Language: en-US From: Kassey Li In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? >>>> >>> >