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 1CB96E77188 for ; Thu, 26 Dec 2024 18:13:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 271706B008A; Thu, 26 Dec 2024 13:13:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 221366B0095; Thu, 26 Dec 2024 13:13:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E91A6B009A; Thu, 26 Dec 2024 13:13:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E49EA6B008A for ; Thu, 26 Dec 2024 13:13:52 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4572C161103 for ; Thu, 26 Dec 2024 18:13:52 +0000 (UTC) X-FDA: 82937907696.15.922FEC5 Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by imf01.hostedemail.com (Postfix) with ESMTP id 49C9740005 for ; Thu, 26 Dec 2024 18:13:18 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=BKn2KeMV; spf=pass (imf01.hostedemail.com: domain of gourry@gourry.net designates 209.85.219.51 as permitted sender) smtp.mailfrom=gourry@gourry.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735236811; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SkOwnM04gSYaxumeHOgniGqId9jfVrv1XuEeE/2uYQg=; b=JE0PpAfz4qxhl8I8uGfwnWrnGCLjIEaNYvdUp+MFDxd4mUDWAF/KaKVE9CRmzqjjN87nax XYGftYD8L1mJS3RuAV0plpyKKkrC/ZfJZNO6BdcXL5ezKuW3R74d9v18ypCqNT5CrRFyDw XmOi9yMwEzrxy5iwGgPKh2gwyvU0uZs= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=BKn2KeMV; spf=pass (imf01.hostedemail.com: domain of gourry@gourry.net designates 209.85.219.51 as permitted sender) smtp.mailfrom=gourry@gourry.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735236811; a=rsa-sha256; cv=none; b=Y5sg1bOAGLarD2R7P+C7v927T/gwO2NwAey4F/Rspw0iFFy4LsTnF1S2uWO0VGXrL6jzrJ 4c9oQ4qIe873/G46Wb05bKSzlS0i8/yeX3Uo3toANNTIKOEankbI2Av1OX/jcYxEnppEi8 DecBM1N0XlpbRuRppFMOOuTnVFPKmT8= Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-6dd420f82e2so288046d6.1 for ; Thu, 26 Dec 2024 10:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1735236829; x=1735841629; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=SkOwnM04gSYaxumeHOgniGqId9jfVrv1XuEeE/2uYQg=; b=BKn2KeMVF1aZb845cTeiFBHMYeFnPYNsQYfisl2F1NtCcYsdoFERfCZICIhc1vhaB4 KhtgBruRSdAqOEQioE9FSmt0MYyliC6Q8PaH5TH4yk0ViNttS1kVnGu1AY+lgzTZjOEH lF/+yZZkIJrJ5NellRVA25UKWJg2rFnYS4p6fVFAmB1iUb2hsCbcNZlUNWvC97yo77Sg Pc+QtAF0WaooYKMaZSw0TwgO0NR5YYGdKtbZ6s/vSSheOHiojBhsMer/iORlnpKT0n62 UtchKMWeJDJ/NKz2b4SLEmnvZKYOLUPmqY7SHEMYXRLkNINF4rcJC7zBsUDPa+KeEtZZ uJOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735236829; x=1735841629; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SkOwnM04gSYaxumeHOgniGqId9jfVrv1XuEeE/2uYQg=; b=WFYkRi2YKnZRBWBCahz7ua5xJLhgIKoPInazpzKG+VIoOspT1qOoTouS5e6oI3jmRW V/gZIpqyR5hNAnVPSzXuClpZMZo43H3jmUSqrth3xbysZkvYHO7WnBKQE8npti1RVL9z Rr0d8dnxTCMUHm2s5M5vDui9BCGeEacrmVQNGUzhJkcdX6tpYjdZyg1lFXy+1CtiusdY wNphQQMdFpgfg1Qr+QtU6QNPcU6OeMNIm4NJHGkqwAmJJg30605hEjZMotDjayZlCOLL I3ZtkfI1fyXpm4zayHUm/2O7jPYJtHgw95uyTMqGF5h44z7faF09YrdmsjL0r8IzWiaA scwQ== X-Forwarded-Encrypted: i=1; AJvYcCUC6tvFPlK0tIPWMqVBXs3CCqXlCB6VSLwLi75RxGTeN2fKC3DbKvpQ5fKyMuEur2CAXjrxHCzaxg==@kvack.org X-Gm-Message-State: AOJu0Yy4/wb6xo1EBbZ6NWpgndpVKbc0fbrgNTytabvruaQf7cwfp8Zq +JvDyYcrhBZ3rAU8p57URNExTe44iVSvoqZ3TGnw3byviVDUTzSF+CQxv3jUgQo= X-Gm-Gg: ASbGncshGNx0lhMPwbxJogeSF/XqF5cCYmgLJ2xGk1K/xPAoqxSSRPtz2kdL+f9weAL xXMq+xzXuDcU6fBcJoGcMNZGHMUcnxf4qsBjcqdIsDRQxQkx1Onrq8y+JVb8iRi8WZA10lhLxDZ eV9rvxJ1Z7vvP+p6Ua2yX8zIxzOMlvY9DERMhRvJyaCaA5O024bCnMnRLXOObdp5EJS9jqP+qtA /g2P8J3lzH01dkaVHKyLmv3VYcooismwlo88jJ15MVS+7WXrKEhWlCb7eWq63FevQMD6ueQ4GT6 Dgpk X-Google-Smtp-Source: AGHT+IEUtGlBtvIBAaSwJqvpGIIc9+7GUi7eXzltAEh/k3pKnpnybjiBzhcqj4Cy/VPQZ/ExExE8gA== X-Received: by 2002:ad4:5d67:0:b0:6d8:86c8:c29a with SMTP id 6a1803df08f44-6dd2331a3cbmr423864206d6.10.1735236829103; Thu, 26 Dec 2024 10:13:49 -0800 (PST) Received: from gourry-fedora-PF4VCD3F ([184.169.45.4]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd181c13b6sm71417116d6.96.2024.12.26.10.13.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Dec 2024 10:13:48 -0800 (PST) From: Gregory Price X-Google-Original-From: Gregory Price Date: Thu, 26 Dec 2024 11:13:21 -0700 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 Message-ID: References: <20241225093042.7710-1-joshua.hahnjy@gmail.com> <874j2rp6or.fsf@DESKTOP-5N7EMDA> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874j2rp6or.fsf@DESKTOP-5N7EMDA> X-Rspamd-Queue-Id: 49C9740005 X-Stat-Signature: umgki7ydwaywyoshzceegf3ji7ahk5pb X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1735236798-829 X-HE-Meta: U2FsdGVkX19v+XL4DWU8///oR454HKLXY/UM/2+efrRgArzY/LlEcl8orkLc4fNPmuOE7QVrKMaLvRuNqsP1DKiWzEHD1mL2DHA0pchmLo5+fXEBGOx+ImmC55WbVCSvxJsucx5t6rRdrcMrdffTQPffC0Z8Tu9uuZ3CGNz/hYXSk8RrQw+Z1BzFTiW1bm3yyf4SNZAD9eSE+XpPBy9/ocdHhetTKHRqTV4aX1MuAuHJzxhfip6rbnwR/A7jJB8rfORiNl4hGkq60oreSCpudZRtQVtktEd+f5/sKN7+d9ctYTo3LOshtKb/BBzlgaibxgX55S2qeJfnivTZ1bwkbnHXu1NNkWBF+N1zwgwu6qJD/uOrpK9i6DNQGiaSLjdnf+MUWDeunYB50rAMbxRQHy5tg997PKUjGvOaKkN19bjfoof9YB/Rnq+8q0dlmmQ/WozIsgzbiyKiizo9A3U3v/za1qMHP036F7EmB5zdUIXheVNWM1bWkkL5M/3+0Dte+X3oLZT76KRdT44cUAz5At/mLnDQ2OaJ8qafxzgQd564V4l9YRMbFVo2RDHeSfB1OdBoOvt85/iOuGH+buP1eadCqlYSyfnwm4lU6Nd7W14FoRrWBSTjfRivXGAWNr+NUygdJpYuUeMs1nIWp8w5Pdl6ymWekdHGC9DoX9NSFhG0gbYZPjCj8Gb6qqRcGOAFOMDaizLN+f3GMF8+IywykoSWGWgKkjj6PfmmiESV/XSlhemnhElYBG/zDVZk9UGuFMQUaNPdoSB9go0VaoPY1GjCqPYDizhJG5evCJ/SIocmWVT/sbO4QEwy5zwxhs7G+/jFH+dftj+yCHnB66zGeSixQlVtxEvizjp6dKbgEJB4QwueyTnCeYnSFUAiLdThcXJlYb+K7le/QyhhaRpYe/zWTLknOQK4gKnr6NzQLHtYCNSMAIPtTBQacBFonp5r+FS7pJ/SjOqrKTOAl5G ZivfbW0f qjhMCMWLdXdkyba4DVQn2e4QRb7v+Gb+rYGtWwva23sl3ZoEcj6HEK994HQPQSaNVrvSHSh0SeIF7355fqt7Djv0bnr57xERnx47taEaqWqJBm19qkwNnfjd13m195sC5GTcoQIC3uBjsm8XOENO1ZhR6L7A0pfXcPGlklmyRrKcNgsrs5nSFBA8h+IdrloDHHAHxH+Ii+RYGB5qqU4xqrcx0etk9YZXyVKlm/6nva4FSqf4FwYf/Kx0Y6j2Gjtgna2Iz06cGpzozgLjphoWEQ57eyORcNTzgMVSg5USmAZMa6o9qBjCBXZjyuxjtdzdlAaPDvgIYcK3SgTqjcC7Rg1oeBU8ArZdphUgn+MGul2xjZc7kDPoSmsw2nagfVib89Q57Q5OdWVE8JTqitclsdWX8hnS2ABfRNsvUAeVyP1mVolsJrBsZg1gh8hmFI+wy/6oWrDbvXNUTs6y+XgL8aebM6hzeuctAb1CFwptf6q9IAQ8= 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 Thu, Dec 26, 2024 at 09:35:32AM +0800, Huang, Ying wrote: > > 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] > > AFAIK, this breaks the sysfs attribute format rule as follows. > > https://docs.kernel.org/filesystems/sysfs.html#attributes > > It's hard to use array sysfs attribute here too. Because the node ID > may be non-consecutive. This makes it hard to read. > Would generally agree. I think essentially a use_defaults => (0 | 1) interface is probably the best we can do. Setting any node changes use_defaults from 1 => 0 echoing 1 into use_default clears user_values This still allows 0 to be a manual "reset specific node to default" mechanism for a specific node, and gives us a clean override. The only question is a matter of hotplug behavior nodes_online: 0,1 default_values: [5,3] user_values : [-,-] event: node1 is taken offline default_values: [5,3] <-- nothing happens event: node1 comes back online with different bandwidth attribute default_values: [6,5] <-- reweight as occured silently event: user sets a custom value (node1 <= 2) default_values: [6,5] user_values: [6,2] <= note, *no reduction* event: node1 is taken offline default_values: [6,5] user_values: [6,2] <= value still present but not used event: node1 comes back online with different bandwidth attribute default_values: [5,3] <-- default reweight has occurred silently user_values : [6,2] <-- user responsible for triggering re-weight The user has the option of echo 1 > /sys/.../weghted_interleave/user_defaults result default_values: [5,3] user_values : [-,-] or echo 0 > /sys/.../weighted_interleave/node1 result default_values: [5,3] user_values : [6,3] <= only node1 is updated, no re-weight Basically, if the user ever sets any value, we never automatically pull new values in, and the admin is responsible for triggering a re-weight (use_default) or manually reweighting *all* nodes - because changing values implies a change in the bandwidth distribution anyway. I think this makes the most sense. ~Gregory