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 3366EC25B75 for ; Mon, 3 Jun 2024 18:45:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 735AB6B0082; Mon, 3 Jun 2024 14:45:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E5896B0083; Mon, 3 Jun 2024 14:45:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AD1C6B0085; Mon, 3 Jun 2024 14:45:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3B2116B0082 for ; Mon, 3 Jun 2024 14:45:07 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AFF42120A6C for ; Mon, 3 Jun 2024 18:45:06 +0000 (UTC) X-FDA: 82190454612.01.DFD507D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id E14944000B for ; Mon, 3 Jun 2024 18:45:04 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qA754UYK; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717440305; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+2YzqMcT03AYD3Wm1n7UDNiWNO+JLNpO8g305vueyuw=; b=3+ZF69saEZycMOXIocjqO6XOy5OwXbVOTCWGquywaaE9YKskhBR2fbDweAxdqVnxG4mdKc rVL2ah/TQusP9JvwDppMkGBsE/Xhgxlcoq3gd7sqVMC8VnvXX6UlCcg0Pbdh6QairvDa7y pWu+nNBx/BdGsopqor8FqCRYElM1J9s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717440305; a=rsa-sha256; cv=none; b=TszAWL2fbiKpivDNdcAom1pTd4VZT6hz2/f6kigHIgvZgFmgfQGBa0JP/sxrlJVwcVsvU6 5jT90m1JtyYw+uX2pyAIqGbEQ8mXxqcRGgha5te3i5b6H8o8SNnwVRRQuJeMiSCwtqHpjx WgjOjvSWy4YVysmYEAZgXuih0/sEU48= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qA754UYK; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C8E4B60F37; Mon, 3 Jun 2024 18:45:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B89BC2BD10; Mon, 3 Jun 2024 18:45:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717440303; bh=VGBp8Um3wObQGvuZF4EnQDH/utHRzJD1Fwno53k5PYo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qA754UYKlUnk+Qhx8Pv/DYBWPN0GFGcXOmvQxad+Kcioj30QdOg5LbY+zGbityjJl KuZvqZag+8nvXagwiJBC/sibN/A7QgQ50C194DrOudHh4/B0MvKhZ7poMVDtcbIBQA E6Z4a+KJKq1+neyXoWmZ5MvdrBGwd3SzKjLv66pmoaA+PlacP0ExZGajcqKcQqCr2V Qx0C4INkmubpZubYdWRLl3wX80XD6wZGlPE08tcId2ZI3GVnF/dE/mGdwJTOr9v5rO s1A+yIe5Rjfdeh6kG3kBuoxGTA4tdSYHZTxTa/LH1dXDxJVS3yTvEdk/WQrmYrMW9l CT1hTtvvYRCZA== From: SeongJae Park To: Alex Rusuf Cc: SeongJae Park , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 2/2] mm/damon/core: implement multi-context support Date: Mon, 3 Jun 2024 11:45:00 -0700 Message-Id: <20240603184500.104495-1-sj@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240602194814.929457-1-yorha.op@gmail.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: gsq75bcr6bc9ia554mzi43yukicsfj7o X-Rspamd-Queue-Id: E14944000B X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1717440304-192303 X-HE-Meta: U2FsdGVkX1+lRmbju4+8cZ73ghxnPS6ODIn3i4MTynWFPmoJ19t91QbYy21woxMJt69aKp3xHrcFfCgjcVnV/bJGCDVW3ZLrnopDDMH9fPlEtEalHibJQqWCLPn6BAugyXItlbbxIG9+QjzEusRLTvddEr6aACu7Mj8sQ72rBbsZyeANHPUhDL+Rl+9laQDf4IkzgXC04eznO/TsEtWROr9kRG+naEEj5K1IOTVxKuxIybL3gagAdThSnpRRbS/x41UYgBg9Eso7npFJM/F9ZbPmh5jWu4fHo3pvT6Om9x1sw1giEAdKT61GIORzMXExnA+9VAfw0aN1idT8hhycluyOrEEFl/ea3Ln8osoJ957eOLbC8eYp5LeVX4OaL+DiOmW+VDWoHAdf+LiyV3eRQGvuCedTBxrF8rvzlhPudkV4qqiVVuyITz1qHkJGTA3vS88AUlgnlQotRgjIjX2ZFK+7/Uh+aUtAEb7s7JI2Q2iQGxGTYx1IRXrMFIOLoryTaKD9nBST57KFbJ6NzloCj0JGiIQ23ro0ddpbkzbhV963mPqFZEUbAJFR/e314LcOLzjsdGA6C89X8/VbyrRlLVxuBM7VYCARX7T4yafQpVo3BkPT2EXKjN6pc4Ki7ADDi50p3jZ3GG1ecOeLhp+s1xDc/9b9VXNDLt7VOA6SiIVhLhN+NArzxLRpi2DpKHc0yTkdSlRG9ydW6Fv+jbC+HfrgPJr/nc0p5dLvtRTtsIORolnzEpIUglmk/BRn5J0/wBGaTNzr/qn3tu+xze/p3fekCSsnyhmMDn8o5/5QkrEwQBpF0d9grPP5qm+xFEojidzzBtdDi2PKwHJdOeIZ02I1hXH1FRBh6nLUOAvh+SxLh/vkZess0NcSxXcOfjy1t+keGAJQkllPjiSNYfLkxTZGroxvi4oMZaBu1xpLaC+nqmdZXH9rn1AxWBdrFw39IMVxZWv9Ctm48bCksRG 8ChvzWC/ EvgOzOnLOepo+aRjus09C3CCRuPOT9RcbbjE1rlZ9sqhNWEdaFInVgsZbrFj/X7+2KaB9mIsZpxUhqgwM1wirYWS7BlsJjl0vxRDdYFLW+0qQD4tqJKsFSn7f8qlFp7q9swllNGrhxQi3iyGMt6phwbHYSf+o70M1g0/SEvY06gn/qzSMHb61SfQCpX8+XevYp1GQGlVbYiKUe19Yg4AcBOM3yMGz0QQcsTmRFPwiQZ2G35L5WOb/vP8QDB51iFH9ZYIdK2m++ORD5hM= 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: List-Subscribe: List-Unsubscribe: On Sun, 2 Jun 2024 22:48:14 +0300 Alex Rusuf wrote: > [...] > > > > > > > > > > > > > > > > > > /* private: */ > > > > > /* for waiting until the execution of the kdamond_fn is started */ > > > > > @@ -634,7 +632,10 @@ struct damon_ctx { > > > > > * update > > > > > */ > > > > > unsigned long next_ops_update_sis; > > > > > + /* upper limit for each monitoring region */ > > > > > unsigned long sz_limit; > > > > > + /* marker to check if context is valid */ > > > > > + bool valid; > > > > > > > > What is the validity? > > > > > > This is a "flag" which indicates that the context is "valid" for kdamond > > > to be able to call ->check_accesses() on it. Because we have many contexts > > > we need a way to identify which context is valid while iterating over > > > all of them (please, see kdamond_prepare_access_checks_ctx() function). > > > > It's still not very clear to me. When it is "valid" or not for kdamond to be > > able to call ->check_accesses()? I assume you mean it is valid if the > > monitoring operations set's ->target_valid() returns zero? > > > > The callback is not for preventing unnecessary ->check_accesses(), but for > > knowing if continuing the monitoring makes sense or not. For example, the > > callback of 'vaddr' operation set checks if the virtual address space still > > exists (whether the target process is still running) Calling > > ->check_accesses() for ->target_valid() returned non-zero target is totally ok, > > though it is meaningless. And therefore kdamond stops if it returns non-zero. > > > > > > > > Maybe name should be changed, > > > > At least some more detailed comment would be appreciated, imo. > > > > > but now I don't see a way how we could merge > > > this into kdamond_valid_ctx() or so, because the main cause of this "valid" > > > bit is that there's no more "valid" targets for this context, but also we could > > > have ->after_sampling() returned something bad. > > > > As mentioned above, calling ->check_accesses() or others towards invalidated > > targets (e.g., terminated processes's virtual address spaces) should be ok, if > > any of the targets are still valid. So I don't show special technical > > difficulties here. Please let me know if I'm missing something. > > This is true in case of only 1 context. kdamond can be stopped if there's > no valid targets for this context (e.g. no address space exists anymore), > but when there are many contexts we need to check if any of contexts has > valid target(s). For example, we have 3 contexts per kdamond, at some > point of time we have 1st context having no valid targets (process has been > finished), but other 2 contexts do have valid targets, so we don't need > to call ->prepare_access_checks() and ->check_accesses() as well for 1st > context, but we do need to call them for other contexts. Yes, we don't need to. Nonetheless, calling ->prepare_access_checks() is also not a big problem, right? If I'm not wrong, I don't want to add more complexity for unclear benefit. In other words, I think simply letting a kdamond continues access monitoring for virtual address space targets even after the processes are terminated while there are other contexts that need to continue access monitoring is ok, unless it has clear and significant problem. > > We can call ->kdamond_valid_ctx() before calling ->check_accesses(), > but then we also need to check if nothing bad has been returned from > ->after_sampling() call, so that we're allowed to further call > ->check_accesses(). > > I decided to use a "valid" flag inside damon_ctx structure, so > that if this context isn't valid, we will just skip it while > iterating over all contexts. If this is really needed, why don't you simply call ->target_valid() for each target for whenever we need to know if the target is valid? Thanks, SJ [...]