From nobody Sun Feb 8 05:11:00 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 248411F891F; Tue, 7 Jan 2025 20:18:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736281096; cv=none; b=pBt34/b0YNSqIaIpP7wtw6EtCa9W0UTqsbcegENVXcowcmKUxN40X2AVSSB7MtUHQAIcFaiTjWfTJwTs/4OznOPQh7EZ5q76tmttX1E2otsaa+HxegvrPpaNOTT0TW8/3oefp2Q3W7X8h/XApgFrTJtjkPoqrk4ZANOrGfvwu9k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736281096; c=relaxed/simple; bh=HXA5UPYM/GgxhLgL56pBJuUIhF/kTZ/VCy8SKfZbnOs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=bS5x/LGjJsMZC592GYw9kO+K0APjv59kCIfir1ol4oH+AuyFw3UOyIGIORxSn4YEgLSgIjit/Uq/sOsm+sKyAYiIgdqY7KY80kWKH/27GwpA5OdBVofmomUYXFofGqiNmpAXSeThjblnX6zxNyvFqqP3273KJ5hw5It1o97M/2w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AkcueAy9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AkcueAy9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF4E6C4AF0C; Tue, 7 Jan 2025 20:18:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736281096; bh=HXA5UPYM/GgxhLgL56pBJuUIhF/kTZ/VCy8SKfZbnOs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AkcueAy99tJZzibzNuROIjVEKSp3HVa0hplQr2dlkw1Gb4ZhWDBNd/cLD/u/ExntH 1S/U5SbspW4U4kLrmfEBFI6cn8HblH6UfAiESFY4H8iIbszBodE56UyX7SMBYU6WXz HVYY7E7ePgU6U6V+HYBMV5VdL1FLM/XgidFBv/I6K+8a6YcRCd/pjavVsIt5/57KGX MwyETpH0e2xqRJOjCZIdiskc7WpdNznQpjK9OKaF+Mhw9Uqry1eCro0XRRfVCB4ozr KIz6kJd4eaY1KZj4C97MNDy1IZwc1WP6gJErNxNCPX6D5NYyYCj7liTu3SrtGNfBKi z0G4cHcLCp99g== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , Jonathan Corbet , damon@lists.linux.dev, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 07/10] Docs/mm/damon/design: document pass/block filters behaviors Date: Tue, 7 Jan 2025 12:17:36 -0800 Message-Id: <20250107201739.79484-8-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250107201739.79484-1-sj@kernel.org> References: <20250107201739.79484-1-sj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Update DAMOS filters design document to describe the pass/block behavior of filters. Signed-off-by: SeongJae Park --- Documentation/mm/damon/design.rst | 34 +++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/des= ign.rst index 449eb33688c2..3682e719b8a6 100644 --- a/Documentation/mm/damon/design.rst +++ b/Documentation/mm/damon/design.rst @@ -504,9 +504,35 @@ have a list of latency-critical processes. =20 To let users optimize DAMOS schemes with such special knowledge, DAMOS pro= vides a feature called DAMOS filters. The feature allows users to set an arbitr= ary -number of filters for each scheme. Each filter specifies the type of targ= et -memory, and whether it should exclude the memory of the type (filter-out),= or -all except the memory of the type (filter-in). +number of filters for each scheme. Each filter specifies + +- a type of memory (``type``), +- whether it is for the memory of the type or all except the type + (``matching``), and +- whether it is to allow (pass through the filter) or reject (block) apply= ing + the scheme's action to the memory (``pass``). + +When multiple filters are installed, each filter is evaluated in the insta= lled +order. If a part of memory is matched to one of the filter, next filters = are +ignored. If a part of memory is not matched to any of the filters, the de= fault +behavior is applied. That is, as long as it fulfills other conditions of = the +scheme including the access pattern and quotas, the action will be applied= to +the part of the memory. + +For example, let's assume 1) a filter for passing anonymous pages and 2) +another filter for blocking young pages are installed in the order. If a = page +of a region that eligible to apply the scheme's action is an anonymous pag= e, +the scheme's action will be applied to the page regardless of whether it is +young or not, since it matches with the first filter. If the page is not +anonymous but young, the scheme's action will not be applied, since the se= cond +filter blocks it. If the page is neither anonymous nor young, no filter is +involved, so the action will be applied to the page. + +The fact that the action can be applied to any memory as long as no block +filter explicitly excluded it means that installing pass filters without a= ny +block filter after those is same to not installing the pass filters, in te= rms +of the ``action`` applying. Statistics for DAMOS filters will still be +accounted, though. It is therefore still useful for monitoring purpose. =20 For efficient handling of filters, some types of filters are handled by the core layer, while others are handled by operations set. In the latter cas= e, @@ -516,7 +542,7 @@ filter are not counted as the scheme has tried to the r= egion. In contrast, if a memory regions is filtered by an operations set layer-handled filter, it= is counted as the scheme has tried. This difference affects the statistics. =20 -Below types of filters are currently supported. +Below ``type`` of filters are currently supported. =20 - anonymous page - Applied to pages that containing data that not stored in files. --=20 2.39.5