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 EF9D9C021B2 for ; Fri, 21 Feb 2025 01:09:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 632AB280018; Thu, 20 Feb 2025 20:09:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BBD9280017; Thu, 20 Feb 2025 20:09:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 435C0280018; Thu, 20 Feb 2025 20:09:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 22F36280017 for ; Thu, 20 Feb 2025 20:09:51 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B43091402F8 for ; Fri, 21 Feb 2025 01:09:50 +0000 (UTC) X-FDA: 83142169740.12.1AB9B7C Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf22.hostedemail.com (Postfix) with ESMTP id 28A00C0004 for ; Fri, 21 Feb 2025 01:09:49 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eiBCLOx4; spf=pass (imf22.hostedemail.com: domain of sj@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740100189; 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=MQiYXjXXmQDreWAZt+PRqFNnLWAMO0fWamSgEJhep+8=; b=wvxVpipbAT3YjvBm2LYkE8Jv9fwVt8Z3Y1UIbolfAx+rsTc9g39mKZmVfiIx86jpuMY5jR W8dzKgEM4znVfeQl/RR0B0OMP09HClA7vvRrbEFGW+OmilwpEDxuyLVU1brMPccTRSEE9F RidYJ3gLz4UcN/AamH3Zi3Tn5HjmbzY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=eiBCLOx4; spf=pass (imf22.hostedemail.com: domain of sj@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740100189; a=rsa-sha256; cv=none; b=UJ3U8a5jHCJZLRrgiOoZiEAkA4nTQTWPYhn31cIKqh5FwdGB1eHO1RckTTjXw0tHmYwgNb l6HouuVI+fxr6kMxzrzkd4tZBT1WABKSYA822YCDmACb5DckkOsFXHDdpSl0BWOIaU7syD w7u0iJS7v8bu0wFiLR6Cguh0FYVbg+Q= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 9DC8B68323; Fri, 21 Feb 2025 01:09:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C87D5C4CED1; Fri, 21 Feb 2025 01:09:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740100188; bh=FXVRulunC3wqJ1fgi01DQJm3OVjZa45dNnmystm3rDQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eiBCLOx4Aax3YcIDiwPnOhNjtpqwmigZnCNGLzO8W2babK0oMVOqovPyiArugctyW Vs+xZhITFIfOALSqXDVaznWz4lPZN0EOIatr58G6M/FE7VR+jdrc1nBJ75bTXfzBRc qgcZhz5tY39vow1PuBrLn6CJz+wfAqTmvERHUH3Gc2GhGKF/CfOjAKRYUElLcrqfKC +aAhd62gba85E3JxsCHHFuYWjMkJJM8Ub3AYuT0VaQ+i3Aa1Z8uFO0hCYxScbcPkXg Htk8TD44PhhLRSGuKc/WRTD7DihwxbZs2iU3gmF7/3Hjntdf1K+LvUUQyk2yR7c4yq cE0kkldNgI3GA== From: SeongJae Park To: SeongJae Park Cc: Andrew Morton , Jonathan Corbet , damon@lists.linux.dev, kernel-team@meta.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 0/8] mm/damon: auto-tune aggregation interval Date: Thu, 20 Feb 2025 17:09:44 -0800 Message-Id: <20250221010944.40257-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250213014438.145611-1-sj@kernel.org> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 28A00C0004 X-Stat-Signature: 64mogk9eqq4ktcgpufs1xb1a4skuf5ec X-HE-Tag: 1740100189-9838 X-HE-Meta: U2FsdGVkX1/gQrqQaexmTKVGwkkQSkMYab8p16SG0aT5TeZTqjtK2qH2zDJBOqwa+cAswrJVxq/DX79fRxFwBxreB+gt8ubwGCaE5ElcLlwblAAqUJbdGEC4UrU5iz7WCXTPsCx4F3BWKL1Oki97NfLMf+AaxNPY/pd8RXMGOPqu6DButmK0c8wgdLQXLlKXp00BBem3HPZTeZWv2Di2UuZFigbY9P1w3zXjy2R6vS+KzYES28qYc395i+UMJmLKypdcbgbpuw53D2KT4GCuze63/3Y8SlXVJnMN8XtiBRRBJeHRC/TGi/4CQzA4MJB6ZGvHk0jqZIh9CTlXchLVnHAm5jJC32I9QewDmoLkrOsUcnqQBjfgW1S7E41Io6/uRYwaBGF66gX/TMPkcTzUxuIjFNPjNNFUefU/WHpGhQ12//hFDglWm4YEyslcS18fyt50c49ShCxLv4H8nsM1vzRUEsXXD0S6zcywXI2vR8AJwThUtZbF/fel9tBHcYRcmm5S0nyY8HER7zkXE7WcZuGYgMZ+IqAXcSN13GX89aSRYsx0zGLDk2+6+K+zvGxFj2/WWtpGx5HJxUTQdztg6zPaKVMgGhLyHtT1IOW+2pxKjTtfUCPY6dDtKBGH7XkUmNCMTIMHO3rkObn4iriYAO64kMoV49zl+pB2pfrtmgGZuBQA21zI1dWBF2HkU4XYfOHnT+cjIdP3J6X/yK0ISEETxnlQjPg9oasnBae+VoKHlYjO9xUe8f+Fs/2WhqSwBuFRnrhy+4DrajszdLChoPEr+h6CNaJzMqy62bp42suW0q68Yrr7E7qeVFOUJfnPFh6M2djUrrYCGPER0MKUjFkQVZPrE8UpsmDNcRmXGj2161fVnEzKAOggiCd4Z5UMxMmsTCR9/8Uy1PHoM/9XbUeNz9qj8H4lX0R3p0guI4rUZl2n0ctklc+dacDadepWFmU8kuLKzJngYChe3Ie 3KeXm2Z9 2K0iB/P1jaFT8WJvi+PmO25ilJV9Jsd8UzNCvvEFGbLFuXHH53OsBWfP1j86TWPoTSJ1hYiRTUI17PLQgy4VDklcPvelbHvNLBK/5Pw47aZlB0lJP/kRNzxVxjR8lAm1TzFSlwVzHaQgtMealDqBA5pOsoXOtYIKkzDi6imWR8krsP4/36QMuwomEBSMKxq67bDzPDbe+/pvmKpZinxPNbygqakbTDUyL8YxSwCmiRHBMF7M= 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 Wed, 12 Feb 2025 17:44:30 -0800 SeongJae Park wrote: > DAMON requires time-consuming and repetitive aggregation interval > tuning. Introduce a feature for automating it using a feedback loop > that aims an amount of observed access events, like auto-exposing > cameras. [...] > Aim-oriented Feedback-driven Auto-Tuning > ========================================= [...] > we design an automation of aggregation > interval tuning, in a way similar to that of camera auto-exposure > feature. It defines the amount of interesting information as the ratio > of captured access events to total capturing attempts of single snapshot, > or more technically speaking, the ratio of positive access check samples > to total samples within the aggregation interval. It allows the users > to set the target value of the ratio. Once the target is set, the > automation periodically measures the current value of the ratio and > increase or decrease the aggregation interval if the ratio value is > lower or higher than the target. The amount of the change is proportion > to the distance between current value and the target value. > > To avoid auto-tuning goes too long way, let users set minimum and > maximum aggregation interval time. Changing only aggregation interval > while sampling interval is kept make the maximum level of access > frequency in each snapshot, or discernment of regions inconsistent. > Also, unnecessarily short sampling interval causes meaningless > monitoring overhed. The automation therefore adjusts the sampling > interval together with aggregation interval, while keeping the ratio > between the two intervals. Users can set the ratio, or the discernment. I received a concern about a corner case of the metric (positive access check samples ratio) offline. In short, DAMON might find a few discontiguous extremely hot and small regions and let those achieve the target positive access check samples ratio, even with very short aggregation interval. I was able to show the corner case indeed. It started to increase the aggregatiopn interval at the beginning, but it gets reduced as time goes by and region boundaries get converged. It was showing a few very hot 4-8 KiB memory regions that showing maximum nr_accesses even with the low aggregation interval. They made the target samples ratio on their own. So most of other regions looked pretty cold. This means the logic is implemented and designed and work as expected. But, the resulting snapshot is not what we wanted. We wanted the snapshot to show practical amount of differences between regions that we can utilize for better memory management, not the dark and cold space with a few flaming but tiny red dots. It might seem ok if that's the true access pattern of the workload. And that's true. Some workloads would have really biased access pattern that we cannot make useful memory management decision. But, if that's the case, according to our tuning theory, the logic should have maximum aggregation interval. I also worried about this corner case when starting the design. I hence considered[1] having two feedback loop goals, namely the positive access check samples ratio and total size of >0 nr_accesses regions. But I ended up making this RFC with the first metric only for starting with simpler design. I'm still bit skeptical about having multiple goals, and looking for a better single metric. Now I'm thinking observed total access events ratio might make sense to be used instead. That is, DAMON's regions concept assumes every byte of single region shares similar access frequency. For example, having a DAMON region of size 4 KiB and nr_accesses 20 can be interpreted as DAMON has observed 4 * 1024 * 20 access events. For example, below diff on top of this patch series would explain what I'm saying about better than my text. I will do more tests and share more findings on this thread until I post the next spin of this patch series. diff --git a/mm/damon/core.c b/mm/damon/core.c index 3c1f401fcbbb..0635882751cc 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -1428,19 +1428,20 @@ static unsigned long damon_get_intervals_adaptation_bp(struct damon_ctx *c) { struct damon_target *t; struct damon_region *r; - unsigned long nr_regions = 0, access_samples = 0; + unsigned long sz_regions = 0, heats = 0; struct damon_intervals_goal *goal = &c->attrs.intervals_goal; - unsigned long max_samples, target_samples, score_bp; + unsigned long max_heats, target_heats, score_bp; unsigned long adaptation_bp; damon_for_each_target(t, c) { - nr_regions = damon_nr_regions(t); - damon_for_each_region(r, t) - access_samples += r->nr_accesses; + damon_for_each_region(r, t) { + sz_regions += r->ar.end - r->ar.start; + heats += (r->ar.end - r->ar.start) * r->nr_accesses; + } } - max_samples = nr_regions * c->attrs.aggr_samples; - target_samples = max_samples * goal->samples_bp / 10000; - score_bp = access_samples * 10000 / target_samples; + max_heats = sz_regions * c->attrs.aggr_samples; + target_heats = max_heats * goal->samples_bp / 10000; + score_bp = heats * 10000 / target_heats; adaptation_bp = damon_feed_loop_next_input(100000000, score_bp) / 10000; /* [1] https://git.kernel.org/sj/damon-hack/c/b01238ded409828bc427cd037095686483d39faf Thanks, SJ [...]