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 DF9A5C47258 for ; Sun, 28 Jan 2024 16:28:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B1E46B007D; Sun, 28 Jan 2024 11:28:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 361DE6B007E; Sun, 28 Jan 2024 11:28:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 229F66B0080; Sun, 28 Jan 2024 11:28:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 166706B007D for ; Sun, 28 Jan 2024 11:28:14 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D8F02A041E for ; Sun, 28 Jan 2024 16:28:13 +0000 (UTC) X-FDA: 81729252066.22.40A2A26 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf01.hostedemail.com (Postfix) with ESMTP id F202E4000B for ; Sun, 28 Jan 2024 16:28:11 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AquRfRat; spf=pass (imf01.hostedemail.com: domain of sj@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706459292; 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=vIx6wV+X390H1MyhqCuw+YAkGBm8N9TgiWGjbAKwlmE=; b=KXvkgMxQ3SIZJHMbCHJlZgqfaHvlc7iXrxfu+Zk9/UPL9vQ9VrHNAAr91U20oORwXo/ays WvaH2VTf8ShOtL4OjnTW8ue7b/wqjs4lJRpnl2dS6c5If8QjNmGHwIZqW2C0nxADag6/iT vF884Or2BgxYZFYX7tcQMLn2JT5UcB4= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=AquRfRat; spf=pass (imf01.hostedemail.com: domain of sj@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706459292; a=rsa-sha256; cv=none; b=lF6see/Nphnl92L497CqF8Y+Zms2/q0Hh8Er1orvmI1ddBIyuxTqzc4ECWDNFSoGxGFHkv LFkT20tREetvYwAzYOyKdAwLYsLD1C0ICAlOYbt/+Y5p+SMu4faCA52pqg3MsPDmAJdEbo SMDhe0tpoRZ2efnfKNQgmfM63iL68UU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 6435ACE0C54; Sun, 28 Jan 2024 16:28:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06EA5C433C7; Sun, 28 Jan 2024 16:28:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706459286; bh=/W2K331dVIKg1A5n58BV8W/mEY0UJaxcXNBQ+I1OcYc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AquRfRat1KOj7piVyl+sFa7F8s3phwllA7jHYvPOtsqPq1ozuXMsu/C42RmHIRzSf 5fxuwbfZ/2V9/IoKlUdQvnxsrsD/6/SNpjt2E/K/II1DIpNG6xb+sWc5HctqJ8und2 cd9xVu3L97GlW5qNazkFrkKywY4HHl9JhpjUqVvVoSfMA3CYBwBpbphECxGaV2zHaB IpFafXZKa32vDwlxjecKQ+/WvKDZYCUw+iHF/9FeUvrogroeNPFtrv5b1RLLujcD8r bazrqpR6bHbw3BNTbdYMQwxFGHyZAUQlsd2H2pEPlagKyVGQ/+y2VHZyC7LngojsJD QIqn7+jxu34eA== From: SeongJae Park To: cuiyangpei Cc: SeongJae Park , sj@kernel.org, akpm@linux-foundation.org, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, xiongping1@xiaomi.com Subject: Re: [PATCH 1/2] mm/damon/sysfs: Implement recording feature Date: Sun, 28 Jan 2024 08:28:04 -0800 Message-Id: <20240128162804.17866-1-sj@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: F202E4000B X-Rspam-User: X-Stat-Signature: bspd4uwueczgfaqs6qskgnyaz7o4xbpr X-Rspamd-Server: rspam01 X-HE-Tag: 1706459291-725159 X-HE-Meta: U2FsdGVkX19ovk5ImU2lKqoi9X4csM+e/CD2uG5VnuAFHqvhjwzTFZ8t8Nj8BdwVfQDdz0pJLBUblxS2ybvQV+w+W4XS85MhOwsNs7fKtkvLC7UH7XyG95W/sqmj/Zl+T7KOKJSf+5D/i0iHXqc+4xNYw5fHcqWJPxTproNyYscTiDSSofN7hA1N/tnxxuYkJAzn2nahInGb8oYL/hHKTCNKDb+xbM6VJDLhRLAP/v67prpwxvUL5W9hX7t8j2eWmhojVlz/X8jJBHwTA3dyR99ltjT/ZPp9vFBHIpSMnXqmMcMYF7sCd+kAPWDp9SWQikLjbtl+9OX7jKaGnjd00CS3yY6U+aPSYEx0pbubflUCuTFBU28Ns40unp8f8m1R+oog7cUYWfTY+qakOYD6kqyJd5Tpvyb6XW3rEx6aMVBPr0ZSHoy6IRaW3G09KzTmgWfMJSVUDp+Qdi99Gw9svq2sWh9KJT4mQLTYQMiO3eTE7PGT7quQPuRsDpRVpwzOl4ZprnqQGZPdM37ZBBub+3AV3s3eyTESbidV0/DGzZNdRYx7BheRUaRa7e2gTwH2t2lHpF897YOwcTQb7GFdt6x/1suEX+9AHss4aii8RVf/8/Sv467MSA+SU13mHjWhTjNTgw/K4HT9u/Y1N48K6tZNveEvD6ci5WN/PWZNcHK+B/x/Vl4VfqShIlIuLN1g5hGzkpAcphy2awiUpBXutNN8Ob4nDdMFWolVycgd1KLNYL1hm18X2RLbMRSO+AWkyxHEtRJr8cuybCtIhl8RGivSLbisQd2oUCdZbZmBxSA7vnYSvqKTCPcggRvJHiy5beR2jHxKyRpe6A10PywRec6/XdRhjddvPhD20CyAOGxjOvTO8ihmBlUZBhioCKJOnvWCe67o1+WNqvl2PGvJbUwDIs3TsPxaXYGpD5H0bKUCIrhoCwO+0Y5yQSnW9g+Qw/oj+Fv0eAhUXjoLKit Xe+CofDf iPY2hVx3+1PHRrA2b3ZTpjgf51g== 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, 28 Jan 2024 17:13:00 +0800 cuiyangpei wrote: > On Fri, Jan 26, 2024 at 12:04:54AM -0800, SeongJae Park wrote: [...] > > So, 'update_schemes_tried_regions' command is firstly handled by > > 'damon_sysfs_cmd_request_callback()', which is registered as > > after_wmarks_check() and after_aggregation() callback. Hence > > 'update_schemes_tried_regions' command is still effectively working in > > aggregation interval granularity. I think this is what you found, right? > > > Yes. > > If I'm not wrongly understanding your point, I think the concern is valid. I > > think we should make it works in sampling interval granularity. I will try to > > make so. Would that work for your use case? > > > It's much better than working in aggregation interval. Thank you for confirming. I will start working on this. > > I have a question. Why does the 'update_schemes_tried_regions' command need to work > in the sampling time or aggregation time? 'update_schemes_tried_regions' is a > relatively special state that updates the regions that corresponding operation scheme. > Can it be separated from other states and controlled by sysfs node to respond immediately > after being written? Mainly because the region data is updated by a kdamond thread. To safely access the region, the accessor should do some kind of synchronization with the kdamond thread. To minimize such synchronization overhead, DAMON let the API users (kernel components) to register callbacks which kdamond invokes under specific events including 'after_sampling' or 'after_aggregate'. Because the callback is executed in the kdamond thread, callbacks can safely access the data without additional synchronization. DAMON sysfs interface is using the callback mechanism, and hence need to work in the sampling or aggregation times. Thanks, SJ [...]