From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F21B13DBB6 for ; Thu, 26 Dec 2024 18:13:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735236832; cv=none; b=cJ+h+BqwkZ8iXf5fhpBbVhaqZIreM6OzH0L7Pmwa7wYKQQjWStfheN5c1YmibcZoeWpcv4th63TpfqgtOqOCtliMRnUOeumyv3+l4y1iHamobopHdGJHQ3jh5RXIlcg1H0q+3iqLG0YOVamESjOeprz8Wpvrr2vkrvjFH1GSOu0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735236832; c=relaxed/simple; bh=b4QKHYme5yT3asASBjmHflWTpAaOfdad2vw1w15H5zs=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tFgYS6uhnVEEIBzpe1z97jkxq4Sgs5dk2prW3XJoPA7SjBPWXtiRSwKmyRHqZKBBkfhej+AHpaO9ewJ5VCKYChKGlDAGsomkQP3dHPKHWnPbfcmZX7GXnlvG8XlINvEr2hxoLxbOvf2AAClA8e63lhjVGXaQPRPaGdlPyXEV73s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=uJoZPD6k; arc=none smtp.client-ip=209.85.219.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="uJoZPD6k" Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-6dd420f82e2so288056d6.1 for ; Thu, 26 Dec 2024 10:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1735236829; x=1735841629; darn=vger.kernel.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=uJoZPD6k9NbEC5J2Mch4KuQ5H0GSLcaiPXVRor9wnEZyie7u7MBxNQUKpmikRmB4r1 K2jZxHhm0nFHDjMI8kFQ2fjou29pWQ4nd3x9lQ1kalYVEeqLi+BAjJW1bdnUxOZMZW+K aspwcKen6s42zDgtwWyfQfQjm1SPf7lz4UPn3gPtf0b8h024P6ki0esv825mgBonKp6a hKTCt/PsuNrNZZrgAwIKuw80fjHiJdj2XxYupQ9E8J92b++qHBzZv8q+pgKu+iJciOE1 PVjvCwvneb3xk+1Q7AKrbA8cj6byDzSyq7wOF/m2dH2LwfgsRlU9Mrpj4nwBt4cRy1fR DpYA== 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=v3HmLIWW3I89Jcab9onPf68qX+dQcpvEvNDnqLVdYV4G4z2JLepPUFf7N7CkNoV6LY A+L9T6GDujE0RFnRNW3aK45+547lfhWJIGFayqFCdTm3aJo0Rz6amcwnfdTxx+sqZjN8 0T92kw6kmI4A1fpVtD0Em7yTEQIarLYwQ7Azt60hvMZRqRwjEVFCiJFGvHNWpJyCzo/i Zub7Do0vYwoErbWZ5QNEOSLYoFTQNgiJAq6QBQMDGzacINAX0iFD9Onoso5wWuWAJli7 UnT6zBspTY/cPcJo9GK9pzTwkRzw1mapSTNZUb0TGVsG077gLrHN2c0AHxQRBLBcjaFk lEAA== X-Forwarded-Encrypted: i=1; AJvYcCXkbEDbr63KneJ0ilidkKttJWGmWBk8Z6acWaEpYMVyxmZFQMNNOXSNsyTuXBTl6zjI4IJCY7z4NODGYoM=@vger.kernel.org X-Gm-Message-State: AOJu0Yz4h4sRvmASF/ondoM9vsTeuqG6+xd+i8jm75S9wWuFR3elKoPi gSHv8zayD4eFzZxZZiuUjqNKii0Jj71QCgkkAde2AfQhLBlGgVhIU6AqENkQdGE= X-Gm-Gg: ASbGncu9SSsHI5U8T1NrIn/AoerHaFwp7t408aTr2nDsLn70Shzd652v3Fr/0eiQi74 Ehv2r996F66GXQFEeD0CTsXVZJ32durz4FWqbBQjPXZ+KvGMw0bdOrMtDQ39WF2qK046/TO4zOB NuG6+mMeypc0c/m6S/jXDfWS88tiac0AHYWM/5GtrIHxqr6eOK8uo+mcXIUeb/mEiE0Y8Jp0oVt /kA9wNyHTvspXn2Ab+NU8x5q6MlQqKNmaGKxu1SYNhaf7EmlAt/O/Gt4Vj6tlAApN9WwdjBmPiO l388 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874j2rp6or.fsf@DESKTOP-5N7EMDA> 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