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 0B62EC282DE for ; Wed, 5 Mar 2025 19:14:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 155596B0083; Wed, 5 Mar 2025 14:14:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 106A36B0085; Wed, 5 Mar 2025 14:14:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE93A6B0088; Wed, 5 Mar 2025 14:14:48 -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 D00766B0083 for ; Wed, 5 Mar 2025 14:14:48 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CBA3B1C7369 for ; Wed, 5 Mar 2025 09:49:25 +0000 (UTC) X-FDA: 83187024690.16.EE41BC8 Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf01.hostedemail.com (Postfix) with ESMTP id 3BE1440005 for ; Wed, 5 Mar 2025 09:49:22 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf01.hostedemail.com: domain of yunjeong.mun@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=yunjeong.mun@sk.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741168164; a=rsa-sha256; cv=none; b=KImbu48rdIA3EDxEEm8FT29BVl8EvB8oKIBtqKgWqyKBV0AxeP6nTSvU0o2/7VXzI9dr/7 y8Fn5ynmDg8ys5B9f2OjckvuvZS5yqq75iqjlsHaUB1iD7ID4201CQw3qoSNB357iwbdEq Y9c5IDbysHq8ITvmThyJH3foghlqJXE= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf01.hostedemail.com: domain of yunjeong.mun@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=yunjeong.mun@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741168164; 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=2Q7JYXdEvCPOfNJ2HlGTYU8KudOWOVNtyW+qaBByiZI=; b=U6iplcvfu/jvnHCffxQ0RbZ2CWWOaj/yowJ8FnzyYPy9VqfRFWomTM/JqarAdTSY/Tgnlq x9LSBXuAkKl5nrlEcfbqfys/u8lygnQm25+EKGs3fygUHyTkAqrhs+iFu5U7oAdnhgyIg6 zWHx2a23dAx1vvSY2D5Ix4OwPx9O6WE= X-AuditID: a67dfc5b-3c9ff7000001d7ae-66-67c81e2012fe From: Yunjeong Mun To: Joshua Hahn Cc: honggyu.kim@sk.com, gregkh@linuxfoundation.org, rakie.kim@sk.com, akpm@linux-foundation.org, rafael@kernel.org, lenb@kernel.org, dan.j.williams@intel.com, Jonathan.Cameron@huawei.com, dave.jiang@intel.com, horen.chuang@linux.dev, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com, kernel_team@skhynix.com Subject: Re: [PATCH 1/2 v6] mm/mempolicy: Weighted Interleave Auto-tuning Date: Wed, 5 Mar 2025 18:49:11 +0900 Message-ID: <20250305094918.968-1-yunjeong.mun@sk.com> X-Mailer: git-send-email 2.48.1.windows.1 In-Reply-To: <20250304222252.3805581-1-joshua.hahnjy@gmail.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsXC9ZZnoa6C3Il0g79L1C3mrF/DZjF96gVG ixM3G9ksmhevZ7NYvcnX4nb/OVaLVQuvsVkc3zqP3WLfRaCynQ/fslks39fPaHF51xw2i3tr /rNazP0yldmBz+Pwm/fMHjtn3WX3aDnyltVj8Z6XTB6bVnWyeWz6NInd48SM3yweCxumMnvs n7uG3ePcxQqPz5vkArijuGxSUnMyy1KL9O0SuDJ27HrKUnBPumLf3uesDYwLRbsYOTkkBEwk NkyewtrFyAFm33/BCBJmE9CQOHjoJDOILSKgKXGidRKQzcXBLDCdWaLxwUZWkISwgKdE25GV jCC9LAKqEkfuiYCEeQXMJJ437GaFGK8p0XDpHhOIzSlgL7H+zAQWEFtIgEfi1Yb9jBD1ghIn Zz4BizMLyEs0b50NtktCoJ9dYvfFHcwQgyQlDq64wTKBkX8Wkp5ZSHoWMDKtYhTKzCvLTczM MdHLqMzLrNBLzs/dxAiMlWW1f6J3MH66EHyIUYCDUYmHN+DnsXQh1sSy4srcQ4wSHMxKIryv Tx1PF+JNSaysSi3Kjy8qzUktPsQozcGiJM5r9K08RUggPbEkNTs1tSC1CCbLxMEp1cDY6phT d/XtLL6TNYvfF+o05vYtvetlKasS1Hc6IUP1+ptTMomemlbF/H+Z11YlBx5rzelOv7u4ZEPT A5EdazjYp381v3HwRtPNhs2Vd2tezTF/UB33o0jMLGaXx7azRkdF7a6e8BVZeWvh1OKl31O1 d08/+N9c86HlRKtg4wAWf3GnnXvSlJcosRRnJBpqMRcVJwIAREFuWJECAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsXCNUNWR1dB7kS6wc1ecYs569ewWUyfeoHR 4sTNRjaL5sXr2SxWb/K1+PzsNbPF7f5zrBarFl5jszi+dR67xb6LQLWH555ktdj58C2bxfJ9 /YwWl3fNYbO4t+Y/q8XcL1OZLQ5de87qIOhx+M17Zo+ds+6ye7QcecvqsXjPSyaPTas62Tw2 fZrE7nFixm8Wj4UNU5k99s9dw+5x7mKFx7fbHh6LX3xg8vi8SS6AN4rLJiU1J7MstUjfLoEr Y8eupywF96Qr9u19ztrAuFC0i5GDQ0LAROL+C8YuRk4ONgENiYOHTjKD2CICmhInWicB2Vwc zALTmSUaH2xkBUkIC3hKtB1ZyQjSyyKgKnHknghImFfATOJ5w26wEgmg3oZL95hAbE4Be4n1 ZyawgNhCAjwSrzbsZ4SoF5Q4OfMJWJxZQF6ieets5gmMPLOQpGYhSS1gZFrFKJKZV5abmJlj qlecnVGZl1mhl5yfu4kRGBXLav9M3MH45bL7IUYBDkYlHt6An8fShVgTy4orcw8xSnAwK4nw vj51PF2INyWxsiq1KD++qDQntfgQozQHi5I4r1d4aoKQQHpiSWp2ampBahFMlomDU6qBUfzh 3hmsOsqHfncsvrRAYP6JH5PXebVP32S8orPM953JGvmNlevTHsbcq8u72rO85+H+W4k6p+T/ TPgy4Xjjy8x5Om91pky+slbw1z2hhdd1F/WeytwSvl4v1HFleG/8P0FLMa+CjIfvDtpYmF3m SFz4QP5OtMqHkEvZkVNqtykvDHDL+GT2+qoSS3FGoqEWc1FxIgCS39kfhgIAAA== X-CFilter-Loop: Reflected X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 3BE1440005 X-Stat-Signature: 3ehfxna5fuwessrbsyjt6zty5imx9noo X-Rspam-User: X-HE-Tag: 1741168162-631421 X-HE-Meta: U2FsdGVkX1+y/6BmsaRW5IiYaczTmdjBxiCPEjrMWznCyY63ksoix399ktrM148ckNa3giDOc7OollZyqMMPAi6f+kbjdJuqOuRCPGpo7Mb7mgyDboOhagUEjbGLnugGV20G4Fw1w5rs844qFfKM1f6SCf93Tq0mp4ZRoRIpCehYoub/Uzacd3YYTWA+SMFGOhpP/0Srbt8k20D1idevnEbCvYBD9hu3CnB+7EMQ8gM3+VGboKU55VWUusj54EYNX3XUgfokHPRnS4+AtzOmNEIGyQn4xzLwIhwU/VFlU2gE0UVCv/ooltskxf7m1qZ1NzNeVQJbrfuE064XADN5IwTn1L6qW7b7MTUTHK5y4gZTRJ57lBZiBG3/3a88CIe0Rtv1NiSv9pqCJpgdJcSixNHF5FrD20GJo8VVlOKMxEgPoZoKyksHFUo2e+zQTaR6LZ8sCYa168ZSKXdn8EEEjSH9N5ZpRMurAjkXFvqtgs9v5znHC3QFlCkB6FDFgBkWzwPqEj4GDSquNioKK8iWoFvA5jdya5dCwUluSo2DNyCxzwFw0biPZb6fBImbU0+z63X2trHoko6JSe5PpPfEcuA8t0FwefQLj0dI6wXjsfXLll6WUy8QWyTCwdWJtRBinsLdjl0x41S/ztUqcIgjrxUFv1Iir15sseAIYyI4WDK7LZ8m7TNEvGABXNJ+6M37TspU2D4aYojyDePZ1DXC0o7pew6RqUd+O34ClNAUPzQAaT7juuR5w92WDp1c9PlvN/RFWSBxh6qWkJdUiG52RmmtS2SMUFBnUymeqvSE5XTIuBPdQQVOU64of/J4krOmKgZU75x8olv+w4sTJ/EG5YrjUJhvc5npjJPoIh13XNo8AaoPknSKQAocjk7ucS1XLUSdd6auX/Yh5e7cjtClsBQv2qqdZTLb0PGCThFdELv90WC0hIXBGYv9mWXgxDCCqmloWXwbAD0Zp9V/LoB JdEZeqhq gCI5xoUNnvQ48izN5dbmdxDsmmdzn6lKKI6yFG99LnCkLqgV1/vcXYCH9F1ATkuBFSk1iUdk+qQrKvAJklE8YwRG2RgIVLm+k/Dvrtnkh2wf8umWavz3WfqRbk0wGaaMX6uJXX3N40DQ3rwXasdsfBJZgpw== 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: Hi Joshua, thanks for reviewing my patch and for your kind explanation. On Tue, 4 Mar 2025 14:22:51 -0800 Joshua Hahn wrote: > Hi Yunjeong, sorry for the noise, but I have discovered another potential > concern that your patch introduces, which I have explained below. > > On Tue, 4 Mar 2025 13:56:11 -0800 Joshua Hahn wrote: > > > On Fri, 28 Feb 2025 15:39:55 +0900 Yunjeong Mun wrote: > > > > Hi Yunjeong, > > > > While applying your patch, I realized that it re-introduces a build error > > that was fixed in v6, which I am noting below. > > > > > Hi, Joshua. > > > > [...snip...] > > > > > In my understanding, new_iw[nid] values are scaled twice, first to 100 and then to a > > > weightines value of 32. I think this scaling can be done just once, directly > > > to weightness value as follows: > > > > > > diff --git a/mm/mempolicy.c b/mm/mempolicy.c > > > index 50cbb7c047fa..65a7e2baf161 100644 > > > --- a/mm/mempolicy.c > > > +++ b/mm/mempolicy.c > > > @@ -176,47 +176,22 @@ static u8 get_il_weight(int node) > > > static void reduce_interleave_weights(unsigned int *bw, u8 *new_iw) > > > { > > > u64 sum_bw = 0; > > > - unsigned int cast_sum_bw, sum_iw = 0; > > > - unsigned int scaling_factor = 1, iw_gcd = 1; > > > + unsigned int scaling_factor = 1, iw_gcd = 0; > > > int nid; > > > > > > /* Recalculate the bandwidth distribution given the new info */ > > > for_each_node_state(nid, N_MEMORY) > > > sum_bw += bw[nid]; > > > > > > - for (nid = 0; nid < nr_node_ids; nid++) { > > > [...snip...] > ^^^^^^^^^^^^ > When I was originally writing the response, I missed reviewing the contents > inside this snipped section, which looks like this: > if (!node_state(nid, N_MEMORY)) { > new_iw[nid] = 1; > continue; > } > I introduced this check in v6 because without this, we end up with the > possibility of memoryless nodes having a 0 in the table, which can lead to some > problems down the line (e.g. div by 0 in alloc_pages_bulk_weighted_interleave). To prevent division by 0 errors, how about setting new_iw to 1 when it is first created, instead of setting it in the reduce function? > > Respectfully, I would prefer to write my own version that takes your > suggestion, as opposed to applying this patch directly on top of mine so that > we do not introduce the build error or the potential div0. However, v7 will > include your suggestion, so it will go through only one loop as opposed to two. Thanks for considering my suggestion. I look forward to the v7. Best regards, Yunjeong > > Thank you for your feedback again. I hope you have a great day! > Joshua > > > > - /* > > > - * Try not to perform 64-bit division. > > > - * If sum_bw < scaling_factor, then sum_bw < U32_MAX. > > > - * If sum_bw > scaling_factor, then bw[nid] is less than > > > - * 1% of the total bandwidth. Round up to 1%. > > > - */ > > > [...snip...] > > > > We cannot remove this part here, since this is what allows us to divide > > in the next for loop below. sum_bw is a u64, so performing division > > by this value will create a build error for 32-bit machines. I've gone and > > re-added this comment and parts to the bottom part; the logic should not > > change at all from the patch that you proposed (except for the build error). > > [...snip...] > > Sent using hkml (https://github.com/sjp38/hackermail) > >