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 6FFB8C4321E for ; Wed, 30 Nov 2022 06:01:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D69956B0072; Wed, 30 Nov 2022 01:01:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D193C6B0073; Wed, 30 Nov 2022 01:01:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE0E86B0074; Wed, 30 Nov 2022 01:01:43 -0500 (EST) 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 AA5B86B0072 for ; Wed, 30 Nov 2022 01:01:43 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 698C28018F for ; Wed, 30 Nov 2022 06:01:43 +0000 (UTC) X-FDA: 80189062086.01.5630ED0 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf02.hostedemail.com (Postfix) with ESMTP id ED22880012 for ; Wed, 30 Nov 2022 06:01:42 +0000 (UTC) Received: by mail-lf1-f46.google.com with SMTP id be13so25384232lfb.4 for ; Tue, 29 Nov 2022 22:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Dd2bPOSx73YkfI4ietT0CtlJFPAPYcl5w03w++siR3I=; b=VueP3BV9DWQDNRdZ4CP4P+VNS3R/j4lV1uV1cXsTBW0u75pHBOhRYGDAUdYvUErmti 624irIm4wqDMaReKRB30EvyBJ7amP4v+zfVwv2hJUhQyNoe0UAZcezmo2pnlQF6Xrpjh yHfvEx6D1DhBe6VCGE43YjmmeA3fyhA58EgzHePnSXxtFGhySFuXaheY0gqwf1leNssp YKzzaiR/iVoDS8dyWYp/GGWo6hPAsEsTL9CEXKpkfyfwWcFyvSWVxbos+mMe0ELBlrtr BCSxVxIiVT2+ZnQZ3g6aeNXUnk52IIb+bqRn9MbaK0C5Ol58dW3S5HKSmQdCRNC4NppZ OF3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Dd2bPOSx73YkfI4ietT0CtlJFPAPYcl5w03w++siR3I=; b=SmgInFBcjAwKvn0QsyhcHFYiMHSs1hSwD1t8DmSUiFyArLZTi8hK8/LERUFJY2lgge Kn5A6qai2su2Yf8if4Xi4hGNR//TwK+t2IMv/SP3x46+GZMoNNsvUNlcXMYlZ64CxiVx K/ZSYLacLbQnq2RR+P5LWj+nGSW6RdMSGyovzILpFjpKTnKWOgfCFIrgsDrXHSU//xMG 6rnq8BG4VZGdUSeBk7OF6Ys2FUCp3nYVhzeSrTUUGxOoNaVp4PPE6dcDlgzznwLov10d +EzdsDbxEVxhhCNaxbW/KdjZRgp/6hUhN83gfR0B3Tn1uHxABHLcZAZ0YSdr0/PUYP7+ lz7Q== X-Gm-Message-State: ANoB5pnzCEdztFmr5PKtlN2Sz43vFNOUHzLkFBBV3QJcSsSpqd/jqdgL XSkvSSOCcYvP6pc1fQ5tIH+Q2UYpWayvBnRZkoshSu+3RBE= X-Google-Smtp-Source: AA0mqf7q7VYdGDYdxOCSlaJ6L0t8HZDI4fhO1M/d/muCK7Hva5Fqezbch6yxwkGj/aDj8LfChdO+7NneUt+SPFcXc28= X-Received: by 2002:a05:6512:22cf:b0:499:fa38:3da4 with SMTP id g15-20020a05651222cf00b00499fa383da4mr19306949lfu.12.1669788101168; Tue, 29 Nov 2022 22:01:41 -0800 (PST) MIME-Version: 1.0 From: Yun Levi Date: Wed, 30 Nov 2022 15:01:29 +0900 Message-ID: Subject: [Question] Should we reuse target when damon's operation changed? To: SeongJae Park Cc: damon@lists.linux.dev, linux-mm@kvack.org, Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669788103; a=rsa-sha256; cv=none; b=BenHzHUdXjcZX2gmPzREmPFCmhe8HwlNjGAB7mB5iY8+Mu1zJXIzplODs0FCsn0hJv8W1Y 6q5Q9F9oCH9tMGShLOkH0OLoYr8/uiiVXOkEcjHZ6Bi/0N1y/C6N/aOJWhehEPCCKkJgRL 8PWYFcr8Rv3c08zRNzSeRjzJ8R1Cbr0= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VueP3BV9; spf=pass (imf02.hostedemail.com: domain of ppbuk5246@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=ppbuk5246@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669788103; 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-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=Dd2bPOSx73YkfI4ietT0CtlJFPAPYcl5w03w++siR3I=; b=ezeHUOiEPDuEq9p0Hwe8HW03FhzGMVe4/+HMP/rWN/VG6blNXHreDV61AG94zUv2daJm0k nzsKaVEyub84LcQJEXrrzlS1+so7FcgK1uTCT1jKXpIW7nhQB/7YoUHZxjUGrfADczecpd +Qk23KyCipudLsNbjUiWwbaoGi0nGU8= X-Stat-Signature: w6ptqsdxrwmup15gb73z8oj3j6weiray X-Rspamd-Queue-Id: ED22880012 X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VueP3BV9; spf=pass (imf02.hostedemail.com: domain of ppbuk5246@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=ppbuk5246@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam05 X-HE-Tag: 1669788102-332526 X-Bogosity: Ham, tests=bogofilter, spamicity=0.111440, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello SJ. While I try to use damon, I have some questions whether it is correct to reuse damon_target structure when damon's operation is changed. At first, one user set up damon like below. echo 1 > /sys/kernel/mm/damon/admin/kdamonds/nr_kdamonds echo 1 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/nr_contexts echo 1 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/nr_targets echo 1 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/pid_target echo 1 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/regions/nr_regions echo 0 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/regions/nr_regions/0/start echo 16384 > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/targets/regions/nr_regions/0/end echo vaddr > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/operation echo on > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/state And some time pass, user change the operation as "paddr" like below: echo paddr > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/operation echo commit > /sys/kernel/mm/damon/admin/kdamonds/0/contexts/0/state In that situation, the damon_target is reused and the region isn't changed, former region information which damon_region has -- nr_accesse, last_nr_accesss, last_sample addr is kept. But, former accessed information is based on vaddr and changed accessed information should be based on paddr and it seems the wrong information to new applied operation. IIUC, it makes some confusion to kdamond when it merges or splits regions based on above information. So, Is it much better to remove the target and region information when the operation is changed? or should we check whether it's possible to reuse former access information between former and new operation? Thanks. -- Best regards, Levi