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 6A1EEE7718B for ; Wed, 25 Dec 2024 09:30:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC6976B007B; Wed, 25 Dec 2024 04:30:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D75BF6B0083; Wed, 25 Dec 2024 04:30:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BEF8C6B0085; Wed, 25 Dec 2024 04:30:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 98B006B007B for ; Wed, 25 Dec 2024 04:30:56 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1870EAD88E for ; Wed, 25 Dec 2024 09:30:56 +0000 (UTC) X-FDA: 82932959256.17.4C5BC53 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf21.hostedemail.com (Postfix) with ESMTP id 054021C0011 for ; Wed, 25 Dec 2024 09:29:36 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Kyy0pkFF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of joshua.hahnjy@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=joshua.hahnjy@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735119036; 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=AO97famSWHrEcuq4hlOcC1w64yYzM7UM60pMtM7rK8g=; b=rdpwXDl90Q+XDASB+sgGqgci4b9ESAPQj9b5JRasghEhvKZCyLclAZjYmSG0sSwA181Qtz WIwxmmale8VlJyq6fSZEtL5sXK/h0aO4GCPUBJhpiJxGq4tCuLUHMUAI0AidPn3Oc70Nml 6iaHOtT3UEqhTzhzeheiU1ra9J0is1c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735119036; a=rsa-sha256; cv=none; b=DA8clbwPsqzXR4LUuZxbyJzSrLWk68zUfDRZB1wXxEKzJ7c2lMYPmkWS1SbqwLkkD+3qa2 i2w4vgccJRcOAMaAcGLaJ6uitpp7fhBUN5DqK6zBPTDwcc/1OORVxJjoibixj+Yfsh+BmN Qm4B2nj/eHHPlRz23efQKJGdamDjw84= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Kyy0pkFF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of joshua.hahnjy@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=joshua.hahnjy@gmail.com Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-21636268e43so77743455ad.2 for ; Wed, 25 Dec 2024 01:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735119053; x=1735723853; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=AO97famSWHrEcuq4hlOcC1w64yYzM7UM60pMtM7rK8g=; b=Kyy0pkFFuUWEEhxN1WYM1px/OrRSj8Qu9wP4oqb1NkdoWcumr00BCeFpZEUP3IRDuH M/X6YsfR3Nx7czYETDzdznfUx0KcaWtcVtwSPLEkjiDa+KB6R66t+sJ011HZF5SS2cvj KMqFvcXFu88lqS4Ql0Q37c0Ovyx8eqFOvhDF7iyKNbPrQ/1Sje1RaNqsdb1O2ZReK1cJ 3cdEgvVLl7eVoW9OHsnkmiE710k98Ct0xwomYTytHTjNq8qiSNVFS0bQx4tgRjK3M/Qq 8WPAP4Eod2aeoGPM7vlNG5qzXtBaDz9RjMaU6c6r5tWaRFQpaW0nDSIgHyIY3MgqlXst JoPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735119053; x=1735723853; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AO97famSWHrEcuq4hlOcC1w64yYzM7UM60pMtM7rK8g=; b=Z4UpeMgtDhFxnhbJX8qG9SJxwj/fvePkEhhb6G+YjGtVGSNwAiYlOq+QVGbewe9UD6 bs6OvgR7Lz4BZOsDKQquT+1XJ+D7g47wZVZmEbJ604HcEGKoN0HZqYRtbk5xlTjVDs9U OicPft1RvSY4K58w+9rBe2vg4+rfGQAlWYWNdAzmxlHZ5QZfU858L2c7NI+tWa4qzckN cWVcFMf1FdPFo7JH7uDNuJpkbr8bg72i46oc0LGiFZjSy5IdtBJ77swsx0dfMHuZ3I4T RxZAo8SaiGyJy6cNRF0c0+JvbTCZD2S6u0HPbuMUmMGF+OVfnMixOXKOKJSeX67S1p8K csdA== X-Forwarded-Encrypted: i=1; AJvYcCX3zu64Shd5l2prcBOGLXYSE8Av74+lio7uHO55gYt4mH7o7mgKCHq/MBHy3FK6/vRHsU+NeJpasg==@kvack.org X-Gm-Message-State: AOJu0Yy7VXIAnSvEoXdW1A+2kqovfaO4lxXgUZWslTA7HSNmdZWtGuxH d12zVR1Dj+I17j2CG6tJ6hu+IX3cJRS7Jh9f7IdIMUuLZKQ6pLWd X-Gm-Gg: ASbGnctCgrHwERgDeKrMYFL3UiMvdHsaK53fPy6iyPGmSu1YAVIb3ec6tIZbbQor2Tc KqyLE/qWdrUL/z8OoqPiuYRWSVibsxld3LtiszZSjdrv+qVkWRdd1iHgu59vyOHxMlW5r1u3wVS hb9gBnxMNAd9Uib2XxRvAGhjTAzoD1A88P7NbTVvilPa4p8tetI75L3POhI8zatXgPk9KCG8N3r 1kn1rOifdslW0nRi/JeIrdjuhBTB3UpEMRXB2CTyzoYXwkOPBnGZKnEPcgZ9HihalYJt5jHsK0I vVTFaO7GMxbZKgXE X-Google-Smtp-Source: AGHT+IE5Xqas8nhS3ukivJ7JRMcaIofPaUbvxgDfDbd0nOxfN+FIpeeIIG0vh84jEBLzk0pYYKKZMw== X-Received: by 2002:a05:6a20:12d2:b0:1e1:3970:d75a with SMTP id adf61e73a8af0-1e5e0458eadmr34130497637.9.1735119052670; Wed, 25 Dec 2024 01:30:52 -0800 (PST) Received: from localhost.localdomain ([112.169.183.107]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72aad8dd1a8sm11291909b3a.106.2024.12.25.01.30.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Dec 2024 01:30:51 -0800 (PST) From: Joshua Hahn To: "Huang, Ying" Cc: Joshua Hahn , Gregory Price , hyeonggon.yoo@sk.com, kernel_team@skhynix.com, "rafael@kernel.org" , "lenb@kernel.org" , "gregkh@linuxfoundation.org" , "akpm@linux-foundation.org" , =?utf-8?B?6rmA7ZmN6recKEtJTSBIT05HR1lVKQ==?= System SW , =?utf-8?B?6rmA65296riwKEtJTSBSQUtJRSk=?= System SW , "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: [External Mail] [RFC PATCH] mm/mempolicy: Weighted interleave auto-tuning Date: Wed, 25 Dec 2024 18:30:42 +0900 Message-Id: <20241225093042.7710-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.39.0 In-Reply-To: <87ed1wa9sm.fsf@DESKTOP-5N7EMDA> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: ztn37bs1j8iuqh5d6j3anwykr1545gxd X-Rspamd-Queue-Id: 054021C0011 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1735118976-577591 X-HE-Meta: U2FsdGVkX1/VDnE7i7xR2aezz7FTcmEj+jEl4SxE1WzuFKdfxGfYvvhVn8iQlkBDb+VWj79bOj1vI/nr9s/t/BAXZNQjT4/wbvLqevpIAqAoPakakJ51h5Jf4AWgZEtoAADX83tJIXfLS2lJjyjeW0vZiWq0nD7dBaZdx+5r2SsULwQ48TAbR64o4V0+2pN3g+0vN/A+QOXaHIFIW03GgisvZ2X4H/QDUOk15YScw9Zg/lt7qnEpQJNSm3cSM6V3oUgtnJUodHEMWW99zP0U5LoO43aAfyM1CF89TSsrmQVfKwrYz8JA/DlOcAyBWdnMAbtiNAEhJDQvr0C4m/OCY4BuQnQ56UyIxVLP6Q0Qrpb52ZZXlo2O56yj3CMnYvMk9TPRdhGl7UKqka/wRPvj7yxtigtesQt0IWhvFinN0j8ZLp+PpPEsl0gvSAFNbs/30jBJC9xjF+HRVE5EUwpVBy3U2i7oqH/o+dG7Gllnw4HAG73uHUE2MLVPLK4hauIVl4WA2PEdVO53Xb9g7QgXikstSOTV2sezABpIy7U76WuntUa/0uYXEyoDu5JtJoxZs24z1Yedc3vzvcftbWvpjd4rmtKvgyO8JkqGDyCznEr3YQfO3N7lKcowpMNxSf3BB4S1COb1XYquYVDu6v/R1VDD/yUQKVnFcxSodoiXS8u+36l3832ILdXzu4dOqzzBtcqzSQUrnfcKMEXaFnkKqnJ4TYWE8epCBIokIHTnchtKa56fuzsu5Hp2XmLMLfCNA5hq1cKIQnM+FX88X9yiLprq8/yZHV6wthEkBatwD0LSVQ15TCKiEWPr15eIPMG0CX4FN1Qa/CDcml9ZVUucJjjY6O1eMbPMM+JMfAuRJWflIgfjMzM2K2+O6z/1IjoNhsHM0a70LmtRA8nf+uske63u1w7TwHWuStSc2qFL/oUKluElCCFqZtyiPZ2SP3HcCFOwNP9/Ao22IO9Y3Hp 0paNqPCe DFU8nWE1WJg9nD+t2rQWIUWhaKHn/1y127Sjxy00a9eGr4bY6XAQb7jFlaaPfS/LBsyfCEmETbtyCGKPdhs0dhdkKgOgJuobCLbZ1vRoOJQY8rW1tGu4/Cg4Wxkj3yiiIWuQLJCI7DnQv88a6FwZT/5NTK7yK/lUmc7S6449LnGzjPERb8q4U9abE0qHpbbQ28mijI94bnnoKO5maFFgG5wg6I5hEE+if2f3+OAbrlX6LL9Nj9hqb5F6GOzPRDIfq3lJlLhycoMpDm5giCeRSKGQBKdOEbWRMODJVAIPrfheovGjRUz+n9eP83UcbG3ZQvVedIAm0yiDorJIwhq8jGHrc9NVaqnRXZRuP3yLSQCyX51swV/NknLg9E/3bm3ouSnGqV57cVMxuMsPS/r74IufWtWSL+Y15XfGTHKzCfPy/TgO1giDzuurY8M8eBis6ioNZuM87ZWm65kBC92w2Lnpe6oisTmmKs1UJczch+JUuiGMbHU8bvVQHRNAFqfdHR+41mcyd6nt+3dY02Y4Qq3wOexG6tveSoBYIcn3FmNNtgjnONM/3HMCDP33AX4MpIyn38wlLKO215pM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.168619, 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 Gregory and Huang, Sorry for the silence on my end for the past few days. I decided to take some time off of the computer, but I should be more reponsive now! On Wed, 25 Dec 2024 08:25:13 +0800 "Huang, Ying" wrote: > Gregory Price writes: > > > On Sun, Dec 22, 2024 at 04:29:30PM +0800, Huang, Ying wrote: > >> Gregory Price writes: > >> > >> > On Sat, Dec 21, 2024 at 01:57:58PM +0800, Huang, Ying wrote: [.....8<.....] > > We decided when implementing weights that 0 was a special value that > > reverts to the system default: > > > > Writing an empty string or `0` will reset the weight to the > > system default. The system default may be set by the kernel > > or drivers at boot or during hotplug events. > > > > I'm ok pulling the default weights in collectively once the first one is > > written, but 0 is an invalid value which causes issues. > > > > We went through that when we initially implemented the feature w/ task-local > > weights and why the help function overrides it to 1 if it's ever seen. > > > > We'll revert back to our initial implementation w/ default_iw_table and > > iw_table - where iw_table contains user-defined weights. Writing a 0 to > > iw_table[N] will allow get_il_weight() to retrieve default_iw_table[N] > > as the docs imply it should. > > So, the suggested behavior becomes the following? > > default_values [5,2,-] <- 1 node not set, expected to be hotplugged > user_values [4,2,1] <- user has only set one value, not populated nodes have value 1 > effective [4,2,1] > > hotplug event > default_values [2,1,1] - reweight has occurred > user_values [4,2,1] > effective [4,2,1] Yes, I think this was the intended effect when we were discussing what interface made the most sense. > Even if so, we still have another issue. The effective values may be a > combination of default_values and user_values and it's hard for users to > identify which one is from default_values and subject to change. For > example, > > user reset weight of node 0 to default: echo 0 > node0 > default_values [2,1,1] > user_values [0,2,1] > effective [2,2,1] > > change the default again > default_values [3,1,1] - reweight again > user_values [0,2,1] > effective [3,2,1] Agreed. Actually, this confusion was partly what motivated our new re-work of the patch in v2, which got rid of the default and user layers, and made all internal values transparent to the user as well. That way, there would be no confusion as to the true source of the value, and the user could be aware that re-weighting would impact all values, regardless of whehter they were default values or not. If we are moving away from allowing users to dynamically change the weightiness (max_node_weight) parameter however, then I think that there may be more merit to using the two-level default & user values system to allow for more flexibility. > This is still quite confusing. Another possible solution is to copy the > default value instead, > > user reset weight of node 0 to default: echo 0 > node0 > default_values [2,1,1] > user_values [2,2,1] - copy default value when echo 0 > effective [2,2,1] > > change the default again > default_values [3,1,1] - reweight again > user_values [2,2,1] > effective [2,2,1] This makes a lot sense to me, I think it lets us keep both the transparency of the new one-layered system and all the benefits that come with having default values that can adapt to hotplug events. One thing we should consider is that the user should probably be able to check what the default value is for a given node before deciding to copy that value over to the weight table. Having two files for each node (nodeN, defaultN) seems a bit too cluttered for the user perspective. Making the nodeN interfaces serve multiple purposes (i.e. echo -1 into the nodes will output the default value for that node) also seems a bit too complicated as well, in my opinion. Maybe having a file 'weight_tables' that contains a table of default/user/effective weights (as have been used in these conversations) might be useful for the user? (Or maybe just the defaults) Then a workflow for the user may be as such: $ cat /sys/kernel/mm/mempolicy/weighted_interleave/weight_tables default vales: [4,7,2] user values: [-,-,-] effective: [4,7,2] $ echo 4 > /sys/kernel/mm/mempolicy/weighted_interleave/node2 4 ... > The remaining issue is that we cannot revert to default atomically. > That is, user_values may becomea combination of old and new > default_values if users echo 0 to each node one by one when kernel is > changing default_values. To resolve this, we may add another interface > to do that, for example, "use_default". > > echo 1 > use_default > > will use default_values for all nodes. We can check whether we are > using default via > > cat use_default Like mentioned in the previous comments, I think that the "setting one value to set all the others" is a good method, especially since the more I think about it (in my limited experience), I think there is rarely a scenario where a user wants to use a hybrid of manually-set and default values and is switching back and forth between default and manual values. > Anyway, I think that we need a thorough thought about the user space > interface. And add good document, at least in change log. It's really > hard to make user space interface right. > > I'm open to better user space interface design. I agree with this, thank you for your feedback. I think there has been a lot of great points raised in these conversations, and I will do my best to take these comments into consideration when writing better documentation. > --- > Best Regards, > Huang, Ying Thank you for your input! I hope you have a great day and happy holidays! Joshua