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 8483BE7717F for ; Mon, 16 Dec 2024 07:53:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEBEE6B007B; Mon, 16 Dec 2024 02:53:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E9BFE6B0082; Mon, 16 Dec 2024 02:53:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D63BE6B0085; Mon, 16 Dec 2024 02:53:54 -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 AEF726B007B for ; Mon, 16 Dec 2024 02:53:54 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2EEB31A0880 for ; Mon, 16 Dec 2024 07:53:54 +0000 (UTC) X-FDA: 82900057464.23.823425B Received: from invmail3.skhynix.com (exvmail3.skhynix.com [166.125.252.90]) by imf21.hostedemail.com (Postfix) with ESMTP id 121861C0002 for ; Mon, 16 Dec 2024 07:52:55 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of hyeonggon.yoo@sk.com designates 166.125.252.90 as permitted sender) smtp.mailfrom=hyeonggon.yoo@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734335605; a=rsa-sha256; cv=none; b=miQ6fT26/+5ZN1yp2C6LCetLT2eK6gf1dufDWrz363VylEfzcWYpITz+X136Z0ZOA1X9yp ptyLDJF/G/IFlld74w29AdPsoTn7sgqmJrmPFf1ZMbNjPnVbQLQCy7D10QXpminxmYMBS2 shj0TXmF3X9o7Kp6nGFRehnn/MSIjGk= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of hyeonggon.yoo@sk.com designates 166.125.252.90 as permitted sender) smtp.mailfrom=hyeonggon.yoo@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734335605; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u6sVv1uoFgnabULxk3NPqLxxCnRt+tUswYJUgSBKi3Y=; b=UYOhhPOTGzW1TPESTNgXZyXp4x+QOL6RHWQbsWVcZPdf/xbRkpIk4kFueq/zEZCniuecTR S3G3i4lZ9U9NdoVdveqE41Y2QWlJBPM9fNpOx2eGY0FzoAcFQOHdUZhRmayuzG0GvrkwaH P+ymdQqEBGIFNvReqoSiLDy1ayvRUoE= X-AuditID: a67dfc59-7a9ff700000194b3-e2-675fdc8c7271 Message-ID: <7ed89f33-6ba0-44c7-b4ea-0c72029fa33b@sk.com> Date: Mon, 16 Dec 2024 16:53:47 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Cc: kernel_team@skhynix.com, 42.hyeyoo@gmail.com, "gourry@gourry.net" , "rafael@kernel.org" , "lenb@kernel.org" , "gregkh@linuxfoundation.org" , "akpm@linux-foundation.org" , =?UTF-8?B?6rmA7ZmN6recKEtJTSBIT05HR1lVKSBTeXN0ZW0gU1c=?= , "ying.huang@linux.alibaba.com" , =?UTF-8?B?6rmA65296riwKEtJTSBSQUtJRSkgU3lzdGVtIFNX?= , "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" Subject: Re: Re: [External Mail] [RFC PATCH] mm/mempolicy: Weighted interleave auto-tuning To: Joshua Hahn References: <4ddfa283-eb64-4032-880b-c19b07e407e1@sk.com> <20241213195754.2676135-1-joshua.hahnjy@gmail.com> Content-Language: en-US From: Hyeonggon Yoo In-Reply-To: <20241213195754.2676135-1-joshua.hahnjy@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsXC9ZZnkW7Pnfh0gw8LVCwm9hhYzFm/hs1i +tQLjBYnbjayWfy8e5zdonnxejaL1Zt8LW73n2O1WLXwGpvF8a3z2C32XQSq3fnwLZvF8n39 jBaXd81hs7i35j+rxdwvU5ktVq/JcBD0OPzmPbPHzll32T262y6ze7QcecvqsXjPSyaPTas6 2Tw2fZrE7nFixm8Wj50PLT0WNkxl9tg/dw27x7mLFR6fN8kF8EZx2aSk5mSWpRbp2yVwZczq 7mIpeCle0fh8BmsD41ThLkZODgkBE4mV+6ayw9gzn21mBrF5BSwlPq36wgRiswioSkzsu8cK EReUODnzCQuILSogL3H/1gywXmaB1+wS3R+dQWxhgRiJ7XeWM4LYIgKaEidaJ4HNFBLIkzi2 djkzRL24xK0n84Hmc3CwCWhJ7OhMBQlzCthLfL92nhWixEyia2sXI4QtL7H97RygVi6gM0+x SyzoP8wCcbOkxMEVN1gmMArOQnLeLCQrZiGZNQvJrAWMLKsYRTLzynITM3OM9YqzMyrzMiv0 kvNzNzECY3dZ7Z/IHYzfLgQfYhTgYFTi4b1wKS5diDWxrLgy9xCjBAezkghvjUlsuhBvSmJl VWpRfnxRaU5q8SFGaQ4WJXFeo2/lKUIC6YklqdmpqQWpRTBZJg5OqQbGOjXrw2uX3MqV5WP+ nsYa07ieeePlBc+9vKquRU1O7Snem7qIOUSg99BZNrl8ljnf5WqcE596f41PUZUwvvVf1+5h uCf36Yprc8P3BwXua3XL1GL8ed6zu8LXZ6HF7d+Bcy4/mTRHZfGUzI8Cr5mOXHQ0eHYpwOE9 k7Sx6Qv9ssSLwTxr2w8osRRnJBpqMRcVJwIAlZmsEdkCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsXCNUOnRLfnTny6wfwlrBYTewws5qxfw2Yx feoFRosTNxvZLH7ePc5u0bx4PZvF6k2+Fp+fvWa2uN1/jtVi1cJrbBbHt85jt9h3Eajh8NyT rBY7H75ls1i+r5/R4vKuOWwW99b8Z7WY+2Uqs8Wha89ZLVavyXAQ8Tj85j2zx85Zd9k9utsu s3u0HHnL6rF4z0smj02rOtk8Nn2axO5xYsZvFo+dDy09FjZMZfbYP3cNu8e5ixUe3257eCx+ 8YHJ4/MmuQD+KC6blNSczLLUIn27BK6MWd1dLAUvxSsan89gbWCcKtzFyMkhIWAiMfPZZmYQ m1fAUuLTqi9MIDaLgKrExL57rBBxQYmTM5+wgNiiAvIS92/NYAexmQVes0t0f3QGsYUFYiS2 31nOCGKLCGhKnGidBDZTSCBP4tja5cwQ9eISt57MB5rPwcEmoCWxozMVJMwpYC/x/dp5VogS M4murV2MELa8xPa3c5gnMPLNQnLFLCSTZiFpmYWkZQEjyypGkcy8stzEzBwzveLsjMq8zAq9 5PzcTYzACF1W+2fSDsZvl90PMQpwMCrx8F64FJcuxJpYVlyZe4hRgoNZSYS3xiQ2XYg3JbGy KrUoP76oNCe1+BCjNAeLkjivV3hqgpBAemJJanZqakFqEUyWiYNTqoHR8P3iud1rdubmmW1I XWe7JJ6tmvVhTuzWH4eOTN6UNf+3pn3y6wgv9QVcdqbTjC+xrGK4eXax90f2G4asXtza2fsY p0kY/zE/Vr5ht/eOB5lOOjxviidfLt8+LWv3g8bL2980VC1fKpKyP8MhVu9Aw/ZDCy+n3Pfl UdjVFie1puX37kf/mNM7lViKMxINtZiLihMBvS4OA8wCAAA= X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 121861C0002 X-Stat-Signature: ki1ico18wahs49mmg3cfobm6js9m9u35 X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1734335575-916542 X-HE-Meta: U2FsdGVkX19TQQp+l/w4pMHytlUc5BgvtsvC8niSmJJFjDb5YlX+4ydWWvj09AgRTisyZGvANFpIDPJDBzVCz4QRj6Pi05qmKDoEXVf4RhnZHUMUVNKNiy862OxD0TWsfmVMeAhwA8W1ffzWJBwQFzZZ8+q5zWyyPXCx8rQpV7yBtiwewr7RcAa6P4V9TsSDmPDoxOqxya8nL9+W5+3MrLuqH88MLcW7FcWOc9Zwuu7/+zLGVzCkLq6comF7rK0YCfLyC0JyxdhcOaetarw/kD1MAPG0I0Hcz2kQEzIsDifZvubs0EQGSn5FV0c1SNgGQ2+2bz2iPaU0+MRkoya/vVDIAbbGGHCRnXZYKfITF5jTpzt3c/XD54VjMb/Tr14+mxFuM80ipL/8Xdtcn0ev1tY4J9FK1opu0Hc9RJNcArnlT1p5RgMAnfcAvdUINFYg8KEDioeBMWExykjuQotI3hd2eMjiXe65X13u/spLffFQS2sJfDCGwkyJRn/k4HX5KJvI4JwZtW6Zymv9pIawYoZlmfpsi1c+JvTTTE4FFgla9fjL75bovlk/pITEvGUQ4jRvxc/3qbvmM5y3vuzig+0XUVpDsa9I/qUN1TP2QpUtmvOHYkHN6UgnQLl+tguhMWv+9GnX8Sc461m1xJ4NwqFUN0CuLqqHSUy9XpIbdjk69eH2ewppRqrYT0GO5N/aS+lN/PTqFXWDWiECVsMOKXswKH7TAuJWZ+mlvOb3xroLA1j32chPOso/t/PBA/yWNbeaVekxNQCSLKnxEEbyNyXaQceOaz0Um8Dacq/TmZ1FAF6/fguD1fuv0bs+si6YH2Tf/qRgW8KQY6sb3pM6s9SJ4gCDny6ISZW2aH4ODgn5Dyk4T2Gs5Lmrrb71CGbh/YCwAr7Sb9dsnc7dCRBC71EQm47At9hTwNR9lR0pnFpbvgezSPpot72DjCJdsXfw1ATzhEdnNyR3lbRSGqi RJAfAKCY ExivhfG+tcac8m4bD0G3psfaazA/McCVoLuhz4MDJNBZUafXQBypu8GHrAGFfACQRtYvFh6p7w1b3p8Xq5+XFcp9NlHJIOn7uTOEoGkpdp7sI7Vrw17MIywHDSdHmbm1KEHvVhkI2D+BqONfJ3ULtOK3TvX+nSJtd0kl2isra9iKybHAn7j5mYLZb55SA6z8LaFdHJBk2jjiUQ1qvTDkixRk7KzoSPDHb3Qn/SUlgIRtjoXumRPi+m/1if17/XJRlrP7h 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 2024-12-14 4:57 AM, Joshua Hahn wrote: > On Fri, 13 Dec 2024 15:19:20 +0900 Hyeonggon Yoo wrote: > >> On 2024-12-11 06:54 AM, Joshua Hahn wrote: >>> This patch introduces an auto-configuration for the interleave weights >>> that aims to balance the two goals of setting node weights to be >>> proportional to their bandwidths and keeping the weight values low. >>> This balance is controlled by a value max_node_weight, which defines the >>> maximum weight a single node can take. >> >> Hi Joshua, >> >> I am wondering how this is going to work for host memory + CXL memory >> interleaving. I guess by "the ACPI table" you mean the ACPI HMAT or CXL >> CDAT, both of which does not provide the bandwidth of host memory. >> If this feature does not consider the bandwidth of host memory, manual >> configuration will be inevitable anyway. > > Hi Hyeonggon, > > Thank you for reviewing my patch! No problem :) > As Gregory showed in his reply, I think it would be possible to get host bandwidth information > using the ACPI HMAT. You're right. I was wrong. I checked on our server, and its bandwidth information was valid for both local memory and CXL memory. Sorry for the noise. > [-----8<-----] > >>> +What: /sys/kernel/mm/mempolicy/weighted_interleave/max_node_weight >>> +Date: December 2024 >>> +Contact: Linux memory management mailing list >>> +Description: Weight limiting / scaling interface >>> + >>> + The maximum interleave weight for a memory node. When it is >>> + updated, any previous changes to interleave weights (i.e. via >>> + the nodeN sysfs interfaces) are ignored, and new weights are >>> + calculated using ACPI-reported bandwidths and scaled. >>> + >> >> At first this paragraph sounded like "previously stored weights are >> discarded after setting max_node_weight", but I think you mean >> "User can override the default values, but defaults values are >> calculated regardless of the values set by the user". Right? > > In the implementation, the first way you interpreted is the correct > description. That is, if a user manually changes a ndoe weight, > then updates the max_node_weight, the previous manual change will > be overwritten by the newly scaled values. > > Does this behavior make sense? Ok. then current implementation overwrites the node weights previously set by the user. I think it makes sense to re-scale all nodes and overwrite manually set node weights, because it's what the knob is meant to do, and the user still can override the weight by setting node weight after updating max_node_weight. By the way, could you please explain which part of this patch implements this rule? IIUC it does not invalidate iw_table after updating these default values, which makes get_il_weight() to use manully set node weights even after updating max_node_weight. (Or probably I just misunderstood the code?) > Have a great day! Have a great day too :) -- Hyeonggon