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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5380C433FE for ; Thu, 14 Oct 2021 06:45:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 401A361053 for ; Thu, 14 Oct 2021 06:45:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 401A361053 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BE9B194001A; Thu, 14 Oct 2021 02:45:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B99F6940009; Thu, 14 Oct 2021 02:45:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A888D94001A; Thu, 14 Oct 2021 02:45:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0021.hostedemail.com [216.40.44.21]) by kanga.kvack.org (Postfix) with ESMTP id 9665D940009 for ; Thu, 14 Oct 2021 02:45:32 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 524FB184218F4 for ; Thu, 14 Oct 2021 06:45:32 +0000 (UTC) X-FDA: 78694106904.32.6430EBF Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf02.hostedemail.com (Postfix) with ESMTP id E2AEB7001A23 for ; Thu, 14 Oct 2021 06:45:30 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 9454F60F21; Thu, 14 Oct 2021 06:45:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1634193931; bh=A7vtA7EguJnBwyoJBmEP4sqGH1ppqg97OGt4QN41RuQ=; h=From:To:Cc:Subject:Date:In-Reply-To:From; b=B3lcSxm3zkNKWPlNcVPF+tV3K6UtDow2eo3vkVkk7uLpz/z5juymLfnEaXhdYBg1g ZXRduK5ocDLdJ0xcq98oxFwagKXZ0Pn/vNEAKOustTNbWwjZYwfVKPlLeb/s039Bcp J2On4C0wWCCD4DK6m+Kd4u12A0aiGgArr6VUQFseSlYnC87lBOHVfjx0JxvN5Or71v zXg5OrIo5cviPC37n9zqbx1f0cdn8/tZB04b8zeMdYfzJF9x9Wz+9momA7Hey6u60m wWBA41xqdM/jQJtULQv0enZFINixBN4JAtKUvQAyDlj+rK+6vtsu4BkIHzkI/dShbR Tct5megKDFs9A== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , Jonathan.Cameron@Huawei.com, amit@kernel.org, benh@kernel.crashing.org, corbet@lwn.net, david@redhat.com, dwmw@amazon.com, elver@google.com, foersleo@amazon.de, gthelen@google.com, markubo@amazon.de, rientjes@google.com, shakeelb@google.com, shuah@kernel.org, linux-damon@amazon.com, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/7] mm/damon/dbgfs: Allow users to set initial monitoring target regions Date: Thu, 14 Oct 2021 06:45:22 +0000 Message-Id: <20211014064522.24455-1-sj@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20211013154535.4aaeaaf9d0182922e405dd1e@linux-foundation.org> X-Rspamd-Queue-Id: E2AEB7001A23 X-Stat-Signature: ukxy5d653rycjgfn3tktmemc4ffntgrg Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=B3lcSxm3; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of sj@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=sj@kernel.org X-Rspamd-Server: rspam02 X-HE-Tag: 1634193930-677578 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, 13 Oct 2021 15:45:35 -0700 Andrew Morton wrote: > On Tue, 12 Oct 2021 20:57:05 +0000 SeongJae Park wrote: > > > Some 'damon-dbgfs' users would want to monitor only a part of the entire > > virtual memory address space. The program interface users in the kernel > > space could use '->before_start()' callback or set the regions inside > > the context struct as they want, but 'damon-dbgfs' users cannot. > > > > For the reason, this commit introduces a new debugfs file called > > 'init_region'. 'damon-dbgfs' users can specify which initial monitoring > > target address regions they want by writing special input to the file. > > The input should describe each region in each line in the below form: > > > > > > > > Note that the regions will be updated to cover entire memory mapped > > regions after a 'regions update interval' is passed. If you want the > > regions to not be updated after the initial setting, you could set the > > interval as a very long time, say, a few decades. > > > > ... > > > > +static int add_init_region(struct damon_ctx *c, > > + unsigned long target_id, struct damon_addr_range *ar) > > +{ > > + struct damon_target *t; > > + struct damon_region *r, *prev; > > + unsigned long id; > > + int rc = -EINVAL; > > + > > + if (ar->start >= ar->end) > > + return -EINVAL; > > + > > + damon_for_each_target(t, c) { > > + id = t->id; > > + if (targetid_is_pid(c)) > > + id = (unsigned long)pid_vnr((struct pid *)id); > > This is a bit ugly. Did you consider making damon_target.id a union of > all the possible types it can contain? This will avoid typecasts, has > documentation value and reflacts what is actually going on. Agreed, thank you for this great comment! I will make it at least before adding another type of monitoring target. Thanks, SJ > > > + if (id == target_id) { > > + r = damon_new_region(ar->start, ar->end); > > + if (!r) > > + return -ENOMEM; > > + damon_add_region(r, t); > > + if (damon_nr_regions(t) > 1) { > > + prev = damon_prev_region(r); > > + if (prev->ar.end > r->ar.start) { > > + damon_destroy_region(r, t); > > + return -EINVAL; > > + } > > + } > > + rc = 0; > > + } > > + } > > + return rc; > > +} > > + > >