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=-10.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 D515FC48BDF for ; Thu, 24 Jun 2021 10:26:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8979761248 for ; Thu, 24 Jun 2021 10:26:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8979761248 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 95A548D0002; Thu, 24 Jun 2021 06:26:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 90A3A6B0070; Thu, 24 Jun 2021 06:26:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7ABC48D0002; Thu, 24 Jun 2021 06:26:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0230.hostedemail.com [216.40.44.230]) by kanga.kvack.org (Postfix) with ESMTP id 47CE96B006C for ; Thu, 24 Jun 2021 06:26:47 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DFEEF8249980 for ; Thu, 24 Jun 2021 10:26:45 +0000 (UTC) X-FDA: 78288238770.31.2448607 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf24.hostedemail.com (Postfix) with ESMTP id 9C35BA000263 for ; Thu, 24 Jun 2021 10:26:45 +0000 (UTC) Received: by mail-qv1-f52.google.com with SMTP id x6so3004633qvx.4 for ; Thu, 24 Jun 2021 03:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to; bh=GGBWy7KblmjWzOLjXRSnKxPbTK1pFfoPIQuuwojTTjw=; b=RziSWFb/goJ5Z5rJNF0zfNVbms3RjEdVvH+SscHcPl30lH8lr6wJk+dZBPUNeRl5zV Fnxo3V/fIMHLIIj2gInVCXXntpMYQF2lc59NE9LYOlIFLpJ6PNFOt/ZpG5OjdKzMX5JV jYvc6ApnimX5bwbDDT7o+2wxXvNrdl2A6Ifvlr8pGjP4VAFCUJpkUVjifd7QJCzX5KLA IKuivI3MUJgbQVRiDPpK2CSpMc5V90WnXgZHjJeIrd6EDUW2hohTbll7QiJL1/UAeOxR 1K2MvqZYAlkBXiadjtQRubBq8yhu8Au3RjB/SBBv64gRPwbgXQ9N1bg1FYBKqjraV5rn s12g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:in-reply-to; bh=GGBWy7KblmjWzOLjXRSnKxPbTK1pFfoPIQuuwojTTjw=; b=R6HtpMCCnwES47el2g6H8eHtP7y0AHDRHrYUhnYabdYY1s5L7Vz0BzUdIKnK+Ml+tA 5br5QNS/L6UWgmbnMUNKlD/B7pD4CCMxWgToqzK90nJljYQxejuYpQII9BGina2Vr1PF L4WpRSGmMjf66J0tFR2ps9MDZhuIcATx10stdns8SmglYgo0CQvreHGDKq+DU0TmJXnB 6PHa9GKmCQKBtGZgEsNPIA/QnqUhOZHVlPuCKPFaMO7a7vYg9K74fgrRlx8eB75tSHaU r56fqUZPb+YCDdKc/slN5qPZ7rcxaXSbDt7FbUfXTnEVcAFGRvwDXY41x4g+xwhZDGFf 4ipQ== X-Gm-Message-State: AOAM530VBu8e4DF4n2rCaSGYkEIS7lwixk74z14j55XHEjLNchrMXFV/ T4yZ8gV2j/WePPnxj+j+f2I= X-Google-Smtp-Source: ABdhPJwx6VMUqBVs5D5s1urjNgPqOJuyGnFRMhDKaTTekxWQDCxg58Ygg1KAqEgbfYoCIzlCIlTg0g== X-Received: by 2002:ad4:51cf:: with SMTP id p15mr4628222qvq.5.1624530405088; Thu, 24 Jun 2021 03:26:45 -0700 (PDT) Received: from localhost.localdomain (ec2-35-169-212-159.compute-1.amazonaws.com. [35.169.212.159]) by smtp.gmail.com with ESMTPSA id w195sm2132842qkb.127.2021.06.24.03.26.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 03:26:44 -0700 (PDT) From: SeongJae Park X-Google-Original-From: SeongJae Park To: Shakeel Butt Cc: SeongJae Park , SeongJae Park , Jonathan.Cameron@huawei.com, acme@kernel.org, alexander.shishkin@linux.intel.com, amit@kernel.org, benh@kernel.crashing.org, Brendan Higgins , Jonathan Corbet , David Hildenbrand , dwmw@amazon.com, Marco Elver , "Du, Fan" , foersleo@amazon.de, greg@kroah.com, Greg Thelen , guoju.fgj@alibaba-inc.com, jgowans@amazon.com, Mel Gorman , mheyne@amazon.de, Minchan Kim , Ingo Molnar , namhyung@kernel.org, "Peter Zijlstra (Intel)" , Rik van Riel , David Rientjes , Steven Rostedt , Mike Rapoport , Shuah Khan , sieberf@amazon.com, snu@zelle79.org, Vlastimil Babka , Vladimir Davydov , zgf574564920@gmail.com, linux-damon@amazon.com, Linux MM , linux-doc@vger.kernel.org, LKML Subject: Re: [PATCH v31 07/13] mm/damon: Implement a debugfs-based user space interface Date: Thu, 24 Jun 2021 10:26:22 +0000 Message-Id: <20210624102623.24563-4-sjpark@amazon.de> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210624102623.24563-1-sjpark@amazon.de> References: <20210624102623.24563-1-sjpark@amazon.de> In-Reply-To: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b="RziSWFb/"; spf=pass (imf24.hostedemail.com: domain of sj38park@gmail.com designates 209.85.219.52 as permitted sender) smtp.mailfrom=sj38park@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: myizt9oooiaextuxoqyhgkrr11r4zw3q X-Rspamd-Queue-Id: 9C35BA000263 X-Rspamd-Server: rspam06 X-HE-Tag: 1624530405-151806 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: From: SeongJae Park On Tue, 22 Jun 2021 11:12:36 -0700 Shakeel Butt wrote: > On Mon, Jun 21, 2021 at 1:31 AM SeongJae Park wrote: > > > > From: SeongJae Park > > > > DAMON is designed to be used by kernel space code such as the memory > > management subsystems, and therefore it provides only kernel space API. > > That said, letting the user space control DAMON could provide some > > benefits to them. For example, it will allow user space to analyze > > their specific workloads and make their own special optimizations. > > > > For such cases, this commit implements a simple DAMON application kernel > > module, namely 'damon-dbgfs', which merely wraps the DAMON api and > > exports those to the user space via the debugfs. > > > > 'damon-dbgfs' exports three files, ``attrs``, ``target_ids``, and > > ``monitor_on`` under its debugfs directory, ``/damon/``. > > > > Attributes > > ---------- > > > > Users can read and write the ``sampling interval``, ``aggregation > > interval``, ``regions update interval``, and min/max number of > > monitoring target regions by reading from and writing to the ``attrs`` > > file. For example, below commands set those values to 5 ms, 100 ms, > > 1,000 ms, 10, 1000 and check it again:: > > > > # cd /damon > > # echo 5000 100000 1000000 10 1000 > attrs > > # cat attrs > > 5000 100000 1000000 10 1000 > > > > Target IDs > > ---------- > > > > Some types of address spaces supports multiple monitoring target. For > > example, the virtual memory address spaces monitoring can have multiple > > processes as the monitoring targets. Users can set the targets by > > writing relevant id values of the targets to, and get the ids of the > > current targets by reading from the ``target_ids`` file. In case of the > > virtual address spaces monitoring, the values should be pids of the > > monitoring target processes. For example, below commands set processes > > having pids 42 and 4242 as the monitoring targets and check it again:: > > > > # cd /damon > > # echo 42 4242 > target_ids > > # cat target_ids > > 42 4242 > > > > Note that setting the target ids doesn't start the monitoring. > > > > Turning On/Off > > -------------- > > > > Setting the files as described above doesn't incur effect unless you > > explicitly start the monitoring. You can start, stop, and check the > > current status of the monitoring by writing to and reading from the > > ``monitor_on`` file. Writing ``on`` to the file starts the monitoring > > of the targets with the attributes. Writing ``off`` to the file stops > > those. DAMON also stops if every targets are invalidated (in case of > > the virtual memory monitoring, target processes are invalidated when > > terminated). Below example commands turn on, off, and check the status > > of DAMON:: > > > > # cd /damon > > # echo on > monitor_on > > # echo off > monitor_on > > # cat monitor_on > > off > > > > Please note that you cannot write to the above-mentioned debugfs files > > while the monitoring is turned on. If you write to the files while > > DAMON is running, an error code such as ``-EBUSY`` will be returned. > > > > Signed-off-by: SeongJae Park > > Reviewed-by: Leonard Foerster > > Reviewed-by: Fernand Sieber > > > The high level comment I have for this patch is the layering of pid > reference counting. The dbgfs should treat the targets as abstract > objects and vaddr should handle the reference counting of pids. More > specifically move find_get_pid from dbgfs to vaddr and to add an > interface to the primitive for set_targets. > > At the moment, the pid reference is taken in dbgfs and put in vaddr. > This will be the source of bugs in future. Good point, and agreed on the problem. But, I'd like to move 'put_pid()' to dbgfs, because I think that would let extending the dbgfs user interface to pidfd a little bit simpler. Also, I think that would be easier to use for in-kernel programming interface usages. If you disagree, please feel free to let me know. Thanks, SeongJae Park