Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1241400pxa; Thu, 20 Aug 2020 06:32:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyvKDNtnNkSQMDTQeGw044JHWW2sUfGfOkEfxnQGx2UM5S8egnny+Rn2Z69jM4PzETWS13k X-Received: by 2002:a17:906:7157:: with SMTP id z23mr1759151ejj.534.1597930360431; Thu, 20 Aug 2020 06:32:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597930360; cv=none; d=google.com; s=arc-20160816; b=SawicWboZoU2bi5zmRJ8P3uCtGKMkts1Rz0F5OxAD9lse5Lg6zY4AZT46ldjl0OLZl b++VUSHT9XfRIb4eBia+iAzIf+7SP0+F/NLp3cLyohuowclKKNQmVzdRmgIW2DTmGIOj +r6nGkEjVsMbExQVLjQ7/6hc97UGDYLj3//rr0Ix/WW2S3sLUSPI2PbTyGBbYLnwKCqP J5NgV/zHaDibdkhrcJpzgOe0nUYVDmYwhCJaay4KHH9x+D6UJzSwxiqW/+t9Ue2D3J2Q BTxfG0UtZuCsbo5pQXLnrHpht9b4D6JL1nweDblMiTKkY1bnOaLjqW7NkjHP7U7fctF2 b+2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=OV4Vp1ofAMr75B75qNJu3AEaL5Ppz0SQTP1brRp/NYI=; b=C4fmXLQnvA6jql04bz6KAh0kKp9NG9BheVKa4aYJWIkZgKwqzuFZXeXNCyYkJ0J6Xe uAT6i82nutTuYERWG2rwcRgd8H2hiae6YC42+r/n85HaVzUJKuqngnYHDn6Xi9UkO1sj zXzfSzzx/O78JcT9bLR/BBtDRMW68b6Ruod+w2IVXKqFwD5gMvp97WbXizTKLP3xom7S q4gs4ihJl60DsWYpZRYc1cj/QvUHYOO2geeSe69SUKs8wpztXacMWOu+pZaMM4sdOoZd BWCvWea1badCmZBNSHbA39NdIgnb80p8kh6/uNszT4kjCpfEH+6CrhSnDKBxanVUkfDD Bi1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=f74DRrmw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e11si1221909ejk.250.2020.08.20.06.32.15; Thu, 20 Aug 2020 06:32:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=f74DRrmw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726978AbgHTN3g (ORCPT + 99 others); Thu, 20 Aug 2020 09:29:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727901AbgHTN1D (ORCPT ); Thu, 20 Aug 2020 09:27:03 -0400 Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B63DEC061385 for ; Thu, 20 Aug 2020 06:27:02 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id v2so1607660ilq.4 for ; Thu, 20 Aug 2020 06:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OV4Vp1ofAMr75B75qNJu3AEaL5Ppz0SQTP1brRp/NYI=; b=f74DRrmw4KTmCMG95Z6yT+SY04V3gPuQ25oxfDNfAFmqUtgBt0belJ/hRAcVrDLTO9 h4iyImcHTzOYXeYLgdZPJMXjsBZq54JJg17f5zj/rt/Ad9CEuMjEY4VDZWT5OnEdAFfm 4mDxLqw1zQi2+vzOQDizjxV3NrnNy4lz6ImhNY7Kg+lucW+u+sfEfgQTiqzgTArSQXFn hSWMLl37nR+87sju2ZhQBqAWVjxkAsyfUEnPThmCRxC1nZg1VibF+GfhA4R6XKzlI/DU rDSl8lguXk1VJ/Cem1iEXdhmlUDgeLAN63mUlOs1kw6nL6pWFhGFkBYHtbfmUXUFikI3 cZcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OV4Vp1ofAMr75B75qNJu3AEaL5Ppz0SQTP1brRp/NYI=; b=pvQveIHLjpE9L1/l2zpEVFjEz5ysxVyqZs0jydREo8UBxmXhG6GzH9QmfaGon+aJNM VixArBNAUb82PLpWJKMVm57XOC15zCkUI0VbyMAfATXn5yDRj6zv09sE4uZXsjA9CaSd QpG7hWOj7iukZyc2S/jy4gy6N3W3eFPvX5Rjg7T1SzJRNRRrTlpjtIgSEw77Q6Tvbl2a WrB1aAeS3xXZ2qNFdWsQK2K4mNfr6l0/S86/sHrLbvbtycw40nOhws+KjZYUCZUeevjo FyXbaqL92bPNIA3CQd4/mcr8ZykUB1gsgbkfuKp40kTZie1qihkBJKdxCabUmF7e9JWM +vbg== X-Gm-Message-State: AOAM5311pWr1WTD7EmNlxTVmSRWWyo/UxwHCXMtKKxQkGPYupzM32DrD YrC45qBuip8/7AjB+Ui7LHvWBATi1GQ3wk8/qv5AyQ== X-Received: by 2002:a92:d7c1:: with SMTP id g1mr2735836ilq.145.1597930021491; Thu, 20 Aug 2020 06:27:01 -0700 (PDT) MIME-Version: 1.0 References: <20200820071647.25280-1-sjpark@amazon.com> In-Reply-To: <20200820071647.25280-1-sjpark@amazon.com> From: Shakeel Butt Date: Thu, 20 Aug 2020 06:26:49 -0700 Message-ID: Subject: Re: [RFC v7 06/10] mm/damon: Implement callbacks for physical memory monitoring To: SeongJae Park Cc: SeongJae Park , Jonathan.Cameron@huawei.com, Andrea Arcangeli , acme@kernel.org, alexander.shishkin@linux.intel.com, amit@kernel.org, benh@kernel.crashing.org, brendan.d.gregg@gmail.com, Brendan Higgins , Qian Cai , Colin Ian King , Jonathan Corbet , David Hildenbrand , dwmw@amazon.com, "Du, Fan" , foersleo@amazon.de, Greg Thelen , Ian Rogers , jolsa@redhat.com, "Kirill A. Shutemov" , mark.rutland@arm.com, Mel Gorman , Minchan Kim , Ingo Molnar , namhyung@kernel.org, "Peter Zijlstra (Intel)" , Randy Dunlap , Rik van Riel , David Rientjes , Steven Rostedt , rppt@kernel.org, sblbir@amazon.com, shuah@kernel.org, sj38.park@gmail.com, snu@amazon.de, Vlastimil Babka , Vladimir Davydov , Yang Shi , Huang Ying , zgf574564920@gmail.com, linux-damon@amazon.com, Linux MM , linux-doc@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 20, 2020 at 12:17 AM SeongJae Park wrote: > > On Wed, 19 Aug 2020 17:26:15 -0700 Shakeel Butt wrote: > > > On Tue, Aug 18, 2020 at 12:27 AM SeongJae Park wrote: > > > > > > From: SeongJae Park > > > > > > This commit implements the four callbacks (->init_target_regions, > > > ->update_target_regions, ->prepare_access_check, and ->check_accesses) > > > for the basic access monitoring of the physical memory address space. > > > By setting the callback pointers to point those, users can easily > > > monitor the accesses to the physical memory. > > > > > > Internally, it uses the PTE Accessed bit, as similar to that of the > > > virtual memory support. Also, it supports only user memory pages, as > > > idle page tracking also does, for the same reason. If the monitoring > > > target physical memory address range contains non-user memory pages, > > > access check of the pages will do nothing but simply treat the pages as > > > not accessed. > > > > > > Users who want to use other access check primitives and/or monitor the > > > non-user memory regions could implement and use their own callbacks. > > > > > > Signed-off-by: SeongJae Park > > [snip] > > > +static void damon_phys_mkold(unsigned long paddr) > > > +{ > > > + struct page *page = damon_phys_get_page(PHYS_PFN(paddr)); > > > + struct rmap_walk_control rwc = { > > > + .rmap_one = damon_page_mkold, > > > + .anon_lock = page_lock_anon_vma_read, > > > + }; > > > + bool need_lock; > > > + > > > + if (!page) > > > + return; > > > + > > > + if (!page_mapped(page) || !page_rmapping(page)) > > > + return; > > > > I don't think you want to skip the unmapped pages. The point of > > physical address space monitoring was to include the monitoring of > > unmapped pages, so, skipping them invalidates the underlying > > motivation. > > I think my answer to your other mail[1] could be an answer to this. Let me > quote some from it: > > ``` > Technically speaking, this patchset introduces an implementation of DAMON's low > level primitives for physical address space of LRU-listed pages. In other > words, it is not designed for cgroups case. Also, please note that this > patchset is only RFC, because it aims to only show the future plan of DAMON and > get opinions about the concept before being serious. It will be serious only > after the DAMON patchset is merged. Maybe I didn' made this point clear in the > CV, sorry. I will state this clearly in the next spin. > ``` The unmapped pages are also LRU pages. Let's forget about the cgroups support for a moment, the only reason to use DAMON's physical address space monitoring is also to track the accesses of unmapped pages otherwise virtual address space monitoring already does the monitoring for mapped pages. > > ``` > So, DAMON is a framework rather than a tool. Though it comes with basic > applications using DAMON as a framework (e.g., the virtual address space low > primitives implementation, DAMON debugfs interface, and the DAMON user space > tool) that could be useful in simple use cases, you need to code your > application on it if your use cases are out of the simple cases. I will also > develop more of such applications for more use-cases, but it will be only after > the framework is complete enough to be merged in the mainline. > ``` > > Of course, we could prioritize the cgroup support if strongly required, though > I still prefer focusing on the framework itself for now. > > [1] https://lore.kernel.org/linux-mm/20200820071052.24271-1-sjpark@amazon.com/ > > > Thanks, > SeongJae Park