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 581B6D690EF for ; Thu, 28 Nov 2024 09:54:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 842356B0083; Thu, 28 Nov 2024 04:54:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F2726B0085; Thu, 28 Nov 2024 04:54:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B9FE6B0088; Thu, 28 Nov 2024 04:54:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4C8B26B0083 for ; Thu, 28 Nov 2024 04:54:05 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 00DE8121808 for ; Thu, 28 Nov 2024 09:54:04 +0000 (UTC) X-FDA: 82835042346.20.85DADF1 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf29.hostedemail.com (Postfix) with ESMTP id 8CC91120008 for ; Thu, 28 Nov 2024 09:53:52 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf29.hostedemail.com: domain of honggyu.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=honggyu.kim@sk.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732787637; a=rsa-sha256; cv=none; b=56YigQNJAKOYoAHYoUi5bXO7/AP03h8t+GFMtnLLMECypcmdlA2Q3kqeqnTTYky8TrlZMA 7x3S437stu96CTrjl0PxhV0+GlP8UT96C1k46RPX/oFXW5csy5RMJHqtSclagU+npu5LgC lyVv2Gw8pUDC26NRyBeZxQmN64mrI70= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf29.hostedemail.com: domain of honggyu.kim@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=honggyu.kim@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732787637; 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; bh=7XT9lEmH6TEJBIqwInGToGPS/2pSfAPeWSp8KseUpz8=; b=He56mrcqrpNBS9/RIXuC7SFBxw2gLkxdE+eEuvgpZGzXQMnvejCHqrGWM1JFzs0Eb+hMW+ OAddJ+kuFcIF7mvHO1ldT1bSIJsxWw00v0Ncn9H62ouQC/1NY1AKwoEpfoFaiEZ7PrThhD eRl6GPpY5wMg6saLvbsi7k2ck6WIntw= X-AuditID: a67dfc5b-3c9ff7000001d7ae-17-67483db703ab From: Honggyu Kim To: SeongJae Park Cc: damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yunjeong Mun , kernel_team@skhynix.com, Honggyu Kim Subject: Re: [RFC PATCH] mm/damon: explain "effective quota" on kernel-doc comment Date: Thu, 28 Nov 2024 18:53:55 +0900 Message-ID: <20241128095357.1530-1-honggyu.kim@sk.com> X-Mailer: git-send-email 2.43.0.windows.1 In-Reply-To: <20241126194347.58155-1-sj@kernel.org> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsXC9ZZnke4OW490g157iyf/f7NaXN41h83i 3pr/rBaHv75hcmDx2LSqk81j06dJ7B4vNs9k9Pi8SS6AJYrLJiU1J7MstUjfLoEro/lQVsEx 6Yr5k3YxNTDOFO1i5OSQEDCR+P1lLyOMffHdDSYQm01ATeLKy0lgtoiAosS5xxdZuxi5OJgF tjBKdC/ZBJYQFgiSOHHjCAuIzSKgKvH96wQ2EJtXwExi6Z1XbBBDNSUeb//JDmJzChhL9E9c wAxiCwnwSLzasJ8Rol5Q4uTMJ2BzmAXkJZq3zmYGWSYhMIFN4vj1L1DXSUocXHGDZQIj/ywk PbOQ9CxgZFrFKJSZV5abmJljopdRmZdZoZecn7uJERiEy2r/RO9g/HQh+BCjAAejEg/vB2P3 dCHWxLLiytxDjBIczEoivAXcQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Rt/KU4QE0hNLUrNT UwtSi2CyTBycUg2M2pOuXT3rOLct4E7dDl2fA0oTQ0wXOV0ym+/hetFzrqeciFznlAS3RNuT Dhfkf67U2rj+fPzuVeZbLa9eKn2kVbpqV3XZCsO7gc4WJTUCX320hVZZTlJdcMF4YUXRshVc M5r8L62TWXrz3P7qgs5dbcwSAlf8Vvirtv9nOZPJvm/1Vamlv76ZKrEUZyQaajEXFScCAGGf 3rk+AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsXCNUNLT3e7rUe6wfUNuhZP/v9mtfj87DWz xeG5J1ktLu+aw2Zxb81/VovDX98wWfzetoLNgd1j06pONo9Nnyaxe7zYPJPR49ttD4/FLz4w eXzeJBfAFsVlk5Kak1mWWqRvl8CV0Xwoq+CYdMX8SbuYGhhninYxcnJICJhIXHx3gwnEZhNQ k7jychKYLSKgKHHu8UXWLkYuDmaBLYwS3Us2gSWEBYIkTtw4wgJiswioSnz/OoENxOYVMJNY eucVG8RQTYnH23+yg9icAsYS/RMXMIPYQgI8Eq827GeEqBeUODnzCdgcZgF5ieats5knMPLM QpKahSS1gJFpFaNIZl5ZbmJmjqlecXZGZV5mhV5yfu4mRmDALav9M3EH45fL7ocYBTgYlXh4 Pxi7pwuxJpYVV+YeYpTgYFYS4S3gBgrxpiRWVqUW5ccXleakFh9ilOZgURLn9QpPTRASSE8s Sc1OTS1ILYLJMnFwSjUwFuT/d/i66K/Eof33Mi/d/3RHvrScdaZa3voNabJ/X8x53PB2ohU3 70SzkM/NBs33SnS/h1zMUDny76QB12vO7Jmp1Q9nxh21/yzfteJx81SmtXPvnPvpoOuVybt9 fqaWaWN94d87zeejlPM2NC/f6Oi7xvT6nenqGaGvY85l3T9/RkjG+vf5D0osxRmJhlrMRcWJ AMSt+Co0AgAA X-CFilter-Loop: Reflected X-Stat-Signature: iwdp3ax1mkr8umatzd4qft1fs8qppuo8 X-Rspam-User: X-Rspamd-Queue-Id: 8CC91120008 X-Rspamd-Server: rspam08 X-HE-Tag: 1732787632-967924 X-HE-Meta: U2FsdGVkX1/Fh1vtigM0vtqxTRCLj5Mg6EkUTwkMw6MIlL4JeqQzFke3uBdGyoVEloeP1aZpBfyNikO57h9USVdHYHqCaGqhCKxdygEp0wr9LHtp8sXYgH77IduvgX9T5kaVgAmTV2oxRhoH1XytRklFz6zgCxnZBayOQMlejekrYLjHZbUc3jvNtQ1n0/Yc+Z7omfEo7jd0SdhJhwsOjjk9soLN33tlUYKr1IxCiF3EmCzQaqZML2thWchdPIP7wv7XbAOaoRvVGJ0FNstSoz1fMaowpAv9uwSMp4M6JcKE6hUtX3MCt4GWoSymsXSeBtEcOlC0rK8FzAKWh1lIqkN8eVX/FSkj8fwucfAxs8Xv8a8nCnc8rmTLOK3zXJsO4PHhFUxKgJFjov7T6c6x16kf0pd3XtNBln6QU6pid9g1TIkj1YucplvuJqSGNu3TZv6iRTtaLXcf7tsp3VE+ADaKzefuy2yJAI+X/AimEytSomjr8VuqoJENtv4+dbeGQf01ZilGPPfcpyCAokjwH+oyCRgMdY56FX8em40185olJSirvdKKWvDdmtbb10qcMNd3h4spVo9n8OsIaxURbVBrfQG3/AddSyeUc4TlNX32jW3ZvplNNYhDYOoLDdG2tD1o5mnfqjflUpBOnP0CXQIMhNbjCec6+XJzFYyJOlStDYVGCvjV4CA/MwdL6A8fhti2Gr0M5pNWID5/YN/jyhRLYN9G4Xw8DfcI3r5reL0AdpnSQ6hSt1P7whEREp62EH3AvCR3eiQkJB6C0ykffawjeQJcD1/VaQzTigk+RzP7i104q/0vVc9XlLk+Ozm7cb1bEEVnehIJzPTbgepl4dJ6tpU/4ymTsZCH018Hji/8iN+V94lrEcSOM6XFzYtTEDa86sSUI3K3Y1PuIGLoOG3ADddQJI+c8htKPnvxciI5I9aSoriqrTAB3ttNKoe8bmMuuHmTqEWe29ey1DT 2tmXW/dR IfeD/IsSC1UITGX8VLs7u/hA5K6F9MGx3JPm9kt22p4N6J94S9t3PgGHXipW1tWptwPsQ2RJVOxkvT6g= 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 Tue, 26 Nov 2024 11:43:47 -0800 SeongJae Park wrote: > On Tue, 26 Nov 2024 17:24:33 +0900 Honggyu Kim wrote: > > > Hi SeongJae, > > > > Thanks very much for the quick response. > > No problem, all owing to your kind report! > > > I think it looks great but I > > have some minor comments so please see my inline comments below. > > > > Thanks, > > Honggyu > > > > On Mon, 25 Nov 2024 16:29:21 -0800 SeongJae Park wrote: > > > The kernel-doc comment for 'struct damos_quota' describes how "effective > > > quota" is calculated, but does not explain what it is. Actually there > > > was an input[1] about it. Add the explanation on the comment. > > > > > > [1] https://github.com/damonitor/damo/issues/17#issuecomment-2497525043 > > > > > > Cc: Yunjeong Mun > > > Cc: Honggyu Kim > > > Signed-off-by: SeongJae Park > > > --- > > > include/linux/damon.h | 10 +++++++--- > > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > > > diff --git a/include/linux/damon.h b/include/linux/damon.h > > > index a67f2c4940e9..a01bfe2ff616 100644 > > > --- a/include/linux/damon.h > > > +++ b/include/linux/damon.h > > > @@ -193,9 +193,13 @@ struct damos_quota_goal { > > > * size quota is set, DAMON tries to apply the action only up to &sz bytes > > > * within &reset_interval. > > > * > > > - * Internally, the time quota is transformed to a size quota using estimated > > > - * throughput of the scheme's action. DAMON then compares it against &sz and > > > - * uses smaller one as the effective quota. > > > + * To convince the different types of quotas and goals, DAMON internally > > > + * converts those into one single size quota called "effective quota". DAMON > > > > Could we use "effective size quota" instead of "effective quota"? > > IMHO, it will better give an idea this is related to "esz" in the code, > > which means effective size. > > The above sentence is saying it as one single "size" quota, so calling it > "effective size quota" here feels like unnecessary duplicates of the word > ("size") to me. I'd like to keep this sentence as is if you don't really mind. Since the time or other goals are eventually transformed into a size quota, I thought the "effective size quota" makes sense but I won't stick to my term here. We originally asked this question about the term "effective" itself as we didn't find an explanation what "effective" means actually in the doc. It'd be better to have more explicit explanation as well. > > > > > + * internally uses it as only one real quota. The convert is made as follows. > > > > (nit) "as only one" can be "as the only one". > > (another nit) "The convert is made" can be "The conversion is made". > > Nice eyes! I will fix those. Thanks, please do! > > > > > + * > > > + * The time quota is transformed to a size quota using estimated throughput of > > > + * the scheme's action. DAMON then compares it against &sz and uses smaller > > > + * one as the effective quota. > > > * > > > * If @goals is not empt, DAMON calculates yet another size quota based on the > > > > We better fix "empt" to "empty" together. > > Nice catch! I will fix so. Ditto. Thanks, Honggyu > > > > > * goals using its internal feedback loop algorithm, for every @reset_interval. > > > -- > > > 2.39.5 > > > > > > Thanks, > SJ