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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EE7BC433E0 for ; Wed, 23 Dec 2020 22:50:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3329D22273 for ; Wed, 23 Dec 2020 22:50:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3329D22273 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8F2048D0057; Wed, 23 Dec 2020 17:50:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 87B108D0026; Wed, 23 Dec 2020 17:50:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7429E8D0057; Wed, 23 Dec 2020 17:50:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id 57D1E8D0026 for ; Wed, 23 Dec 2020 17:50:11 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1C7F53629 for ; Wed, 23 Dec 2020 22:50:11 +0000 (UTC) X-FDA: 77626041822.15.teeth81_060f0ef2746c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id E6C921814B0C7 for ; Wed, 23 Dec 2020 22:50:10 +0000 (UTC) X-HE-Tag: teeth81_060f0ef2746c X-Filterd-Recvd-Size: 5577 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Dec 2020 22:50:10 +0000 (UTC) Received: by mail-lf1-f51.google.com with SMTP id m12so938372lfo.7 for ; Wed, 23 Dec 2020 14:50:10 -0800 (PST) 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=fUg/8XfBmtURDT5lBCWnW6DL77gquz8BfclV7WZ4WGw=; b=WXc/1DGf132PTO1txk0qMQlA5PG0JderjXg2RMviXDYMgUBTpn0MqJXVQrstbdvo6U sKm9x+TNynXiw6fdwNIhfb9WiW73WTA5/GgwZ63RKCfipWjrnCp/3sDrRiqtyLXe/pu/ RrMmKQzJmh06iQw8BhyxXv85Zh3l9UA6Ma1uzb62jIYj+VBrUW+UR+spV0IMA2cM7gvX 1WU4XzoMmfXN4HmmtrpXX/FjhnZfG0j4BuNb3k6ZhbP0/BDUHTMikjqdM0hs5QPto24B dHsBaQcvbYHG/SiToDbByT99rbRC3ga3AiXz2NEi+G5EjGn0LhHJ/kt3qh7dBINn1oiZ LLaQ== 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=fUg/8XfBmtURDT5lBCWnW6DL77gquz8BfclV7WZ4WGw=; b=inb8V60OagnWmTqFChPlJzrS2j/BfjxgPcu7qUu9lenJS7GExXvpLLiHjpCXl7NY1f kEbSBdwXhtCAp+1lKgnVx51WPKslpXOFalyUaf6EY/or85gCqF985D5YNUyf6YEzxsIK TT8a73EdQ+xXuIPQD1mp+j/CT/iLXUNL12oh0GePb3P/AVWsRetvl8PphhmFOTk5ls5M v7LFAjsK/28uPDqJkL18m2yfIHfz+/Mnv+DffT9u+aVAH1f4zjMGsZd1HCSeLcqjHAEq xY0VY7E4Aa5rityU7nkGGJqmUn2x7R49wWP/LtDIt15icuUnqfMZmlbZqPPZQ/Aor9bs 3XvA== X-Gm-Message-State: AOAM532E9oR5UNA7ndakmhGvg62jTq7bNNJcH/5cOhm+IPG9l8tZLbDd HvMmxdCbRcRcNg8afY5ioMjjVFTkJxSxlZQSJ6O1Uw== X-Google-Smtp-Source: ABdhPJz1fu+GYJ9Q4hXNi4+W2DXO1kx8E49h4Uw1p0aYX/QxgzzQ1t8pfpNBN4cRz69zRb7/MqIYJBvXh6tuLD6HBDE= X-Received: by 2002:a2e:9cc3:: with SMTP id g3mr13689242ljj.0.1608763808708; Wed, 23 Dec 2020 14:50:08 -0800 (PST) MIME-Version: 1.0 References: <20201223163317.25979-1-sjpark@amazon.com> In-Reply-To: <20201223163317.25979-1-sjpark@amazon.com> From: Shakeel Butt Date: Wed, 23 Dec 2020 14:49:57 -0800 Message-ID: Subject: Re: [PATCH v23 01/15] mm: Introduce Data Access MONitor (DAMON) 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, Marco Elver , "Du, Fan" , foersleo@amazon.de, Greg Thelen , Ian Rogers , jolsa@redhat.com, "Kirill A. Shutemov" , Mark Rutland , Mel Gorman , Minchan Kim , Ingo Molnar , namhyung@kernel.org, "Peter Zijlstra (Intel)" , Randy Dunlap , Rik van Riel , David Rientjes , Steven Rostedt , Mike Rapoport , sblbir@amazon.com, Shuah Khan , 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" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Dec 23, 2020 at 8:34 AM SeongJae Park wrote: [snip] > > Overall the patch looks good to me. Two concerns I have are if we > > should damon_callback here or with the real user and the regions part > > of primitive abstraction. For the first one, I don't have any strong > > opinion but for the second one I do. > > I'd like to keep 'damon_callback' part here, to let API users know how the > monitoring result will be available to them. > > For the 'regions' part, I will rename relevant things as below in the next > version, to reduce any confusion. > > init_target_regions() -> init() > update_target_regions() -> update() > regions_update_interval -> update_interval > last_regions_update -> last_update > > > > > More specifically the question is if sampling and adaptive region > > adjustment are general enough to be part of core monitoring context? > > Can you give an example of a different primitive/use-case where these > > would be beneficial. > > I think all adress spaces having some spatial locality and monitoring requests > that need to have upper-bound overhead and best-effort accuracy could get > benefit from it. The primitives targetting 'virtual address spaces' and the > 'physical address space' clearly showed the benefit. I am still not much convinced on the 'physical address space' use-case or the way you are presenting it. Anyways I think we start with what you have and if in future there is a use-case where regions adjustment does not make sense, we can change it then.