Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp3227115rwb; Wed, 30 Nov 2022 17:36:59 -0800 (PST) X-Google-Smtp-Source: AA0mqf68o0IDkjykIOOCJangBVHzV2epDAwdIOXn63Kk14xiSE9ITMnd4AWYj/JXHjvgS+UaJalV X-Received: by 2002:a17:90a:bb98:b0:219:6492:1843 with SMTP id v24-20020a17090abb9800b0021964921843mr5924792pjr.128.1669858618979; Wed, 30 Nov 2022 17:36:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669858618; cv=none; d=google.com; s=arc-20160816; b=jnPtHcIRbpxcbQeTsDY4MsdLtdUZH+awADlrj2LgFk6/2AKxCOnY3jt7b0Dule3Z4J +v8udZQDooJLq+ntiGGiOUZxD+LbheHg18hH6kI0bZiOsC9j6BLh42SFJFrIECPNbKRa vOdx4Wg84rS0mDNDnei0WTVYsLZ9tMXj5XJBZc113vwc41WpQT7tx2NpCn/jnLv6f9uQ 5lC2t6qJIkJEgu/cta3Pg7hPas0fWSaUaTn/xMHdo6H2kMADrCgeiXQP1mXJwyF+eMru z6hCqh0bekvdFhdjmrjFgBDprLEced7GPbgG7eU3S4D87aP/87gTndELKwJEc1VhamUl bCdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=LzYr3AN9ivqfjEXu5kJPaUBKXyI7G4New0Byp1StYqo=; b=DkMi1mrz8o9EZMJzmAXOJDZjIF2squaFbLI/dchMTyLuyD5qqIDke17Ubo12Xdy4zM QwGTMpBCMB9RoSdbWreRrdGRiAV3qfyr3WqxYUSh2iDepb4dSfktCvf/RWnonAZc0lIo 4CP/hkUJV6isoN66vRwHrbynD1akyJyv7wGk1QONVadnBsEAwlrKFBhbU0qE6vVuXnzy uxhADDnaLaZP36Nn4dbR0zXSvoK454K+6MFJpYLjQgV0Uf1vVHiU64ZX5zC9tNoCc8cb KTqdLKww5wj+cFoF3JUDmZtpVn4jV9Lw7WJSCWaCFDxEqZjmebKzf1VZZUCFux5zm76S J4LQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uB6Gy53i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b12-20020a630c0c000000b00422c003b4c9si2917979pgl.46.2022.11.30.17.36.48; Wed, 30 Nov 2022 17:36:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uB6Gy53i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229680AbiK3Xbu (ORCPT + 83 others); Wed, 30 Nov 2022 18:31:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50408 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230142AbiK3Xb2 (ORCPT ); Wed, 30 Nov 2022 18:31:28 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 933AD60376 for ; Wed, 30 Nov 2022 15:25:02 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 4F0FEB81D68 for ; Wed, 30 Nov 2022 23:25:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F5B4C433D6; Wed, 30 Nov 2022 23:24:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669850700; bh=gqcFXZHwwBwyWaUhRXSzf2GnKgPLlzaIwX0k3rlJp4Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uB6Gy53iThRwFUtXz0Lrt0gouRzm76Xw6GupSl/Il/ITiYN6eZNV0tlhrGqk76arO zKfEYpxEcumW46KA2Rm49M1isUzl2ZNz4Ps1qN1S7oiU598V+ONGImxHZOqdeidcMO BCW2U161XPLpGcBhLDO6e1aA+tjfOBIa4NZVS4ZiR1hDsQcahacrbQ4JKQLCqmNi29 sgIkgb0goTGHi6rvR5gxo3QV+3p3GYpRUTVV+K8Kto07jywH32KmpW7b00f2A1/m/B bZHOhKDUZGg6ieVvPQxtVRCtLkWkusFmdolNJKgvZnTHCHuOkr8DnuiQJTS3OdyFeq /k2l6pkaSMjvA== From: SeongJae Park To: Yun Levi Cc: SeongJae Park , damon@lists.linux.dev, linux-mm@kvack.org, Linux Kernel Mailing List Subject: Re: [Question] Should we reuse target when damon's operation changed? Date: Wed, 30 Nov 2022 23:24:57 +0000 Message-Id: <20221130232457.56003-1-sj@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Levi, On Wed, 30 Nov 2022 15:01:29 +0900 Yun Levi wrote: > 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? Thank you for the good question and the suggestion. I agree that it could be confusing. Such a scenario could be just a mistake in many cases. However, I'm unsure how we could distinguish the mistake from intended usage. That is, the intended initial monitoring range for previous 'operation' and later one could be really same in some cases, as DAMON doesn't ask it to be strict. After all, DAMON allows users to set the values as much as they want before committing the input, so this looks mistake of the user, not DAMON. Of course DAMON could take care of more things, but in my humble opinion, it's hard to distinguish the mistake from the intended change in a simple way. And I'm not sure if this is a real critical issue that deserves to add some extent of complexity. So unless you know critical issue due to this or have a good way for improving the situation in a simple way, please suggest. If not, I'd suggest to keep this in current simple form. Nevertheless, maybe we could improve this situation by warning this case on the documentation. If you'd like to, please feel free to send a patch for that. Thanks, SJ > > Thanks. > > -- > Best regards, > Levi