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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7AA8FC433EF for ; Fri, 18 Mar 2022 05:13:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B61808D0002; Fri, 18 Mar 2022 01:13:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B11158D0001; Fri, 18 Mar 2022 01:13:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FE8C8D0002; Fri, 18 Mar 2022 01:13:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 917558D0001 for ; Fri, 18 Mar 2022 01:13:23 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 5EBC51214A8 for ; Fri, 18 Mar 2022 05:13:23 +0000 (UTC) X-FDA: 79256338686.15.E78499A Received: from out30-43.freemail.mail.aliyun.com (out30-43.freemail.mail.aliyun.com [115.124.30.43]) by imf21.hostedemail.com (Postfix) with ESMTP id 533401C0003 for ; Fri, 18 Mar 2022 05:13:19 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R471e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04407;MF=xhao@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0V7UWWcn_1647580393; Received: from B-X3VXMD6M-2058.local(mailfrom:xhao@linux.alibaba.com fp:SMTPD_---0V7UWWcn_1647580393) by smtp.aliyun-inc.com(127.0.0.1); Fri, 18 Mar 2022 13:13:14 +0800 From: xhao@linux.alibaba.com Reply-To: xhao@linux.alibaba.com Subject: Re: [RFC PATCH V1 0/3] mm/damon: Add CMA minotor support To: David Hildenbrand , sj@kernel.org Cc: rongwei.wang@linux.alibaba.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Baolin Wang , SeongJae Park References: <6e6ef9fa-3916-3449-954d-efd63a959019@linux.alibaba.com> Message-ID: <611f2ec6-04de-440a-3d54-c2bc34f45cf3@linux.alibaba.com> Date: Fri, 18 Mar 2022 13:13:12 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: kum9c4in3s9t9djd9ku6f7qxomaawrbn Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf21.hostedemail.com: domain of xhao@linux.alibaba.com designates 115.124.30.43 as permitted sender) smtp.mailfrom=xhao@linux.alibaba.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 533401C0003 X-HE-Tag: 1647580399-603680 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000902, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 3/18/22 12:42 AM, David Hildenbrand wrote: > On 17.03.22 08:03, Xin Hao wrote: >> Hi David, >> >> On 3/16/22 11:09 PM, David Hildenbrand wrote: >>> On 15.03.22 17:37, Xin Hao wrote: >>> >>> s/minotor/monitor/ >> Thanks,  i will fix it. >>>> The purpose of these patches is to add CMA memory monitoring function. >>>> In some memory tight scenarios, it will be a good choice to release more >>>> memory by monitoring the CMA memory. >>> I'm sorry, but it's hard to figure out what the target use case should >>> be. Who will release CMA memory and how? Who will monitor that? What are >>> the "some memory tight scenarios"? What's the overall design goal? >> I may not be describing exactly what  i mean，My intention is to find out >> how much of the reserved CMA space is actually used and which is unused, >> For those that are not used, I understand that they can be released by >> cma_release(). Of course, This is just a little personal thought that I >> think is helpful for saving memory. > Hm, not quite. We can place movable allocations on cma areas, to be > migrated away once required for allocations via CMA. So just looking at > the pages allocated within a CMA area doesn't really tell you what's > actually going on. I don't think so,  the damon not looking at the pages allocate, It is constantly monitoring who is using CMA area pages through tracking page access bit in the kernel via the kdamond.x thread, So through damon, it can tell us about  the hot and cold distribution of CMA memory. --cc  SeongJae Park More about damon, you can refer to this link：https://sjp38.github.io/post/damon/ > -- Best Regards! Xin Hao