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 D888DC3DA6E for ; Wed, 3 Jan 2024 06:05:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6DE9F6B00B2; Wed, 3 Jan 2024 01:05:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 68E2E6B0106; Wed, 3 Jan 2024 01:05:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5575E6B0107; Wed, 3 Jan 2024 01:05:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4055D6B00B2 for ; Wed, 3 Jan 2024 01:05:18 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1A3FB40F7C for ; Wed, 3 Jan 2024 06:05:18 +0000 (UTC) X-FDA: 81636962316.18.35DDF81 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by imf17.hostedemail.com (Postfix) with ESMTP id E799840003 for ; Wed, 3 Jan 2024 06:05:15 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VTD61GWX; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf17.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.65 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704261916; 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=uFQ98D/CZtfzkuyBHkoMJFLTy3NV+uQ49AfyOSj4pRw=; b=ZcJMoJ1fHAtEkIhnKku6fUNr8VktoIKTxmBdnawxIczvX3wK8/6zZbQbGRWfkW9zlpN57f Pw1fNYR24cn37h4ZZeCwCho4I0mH0Ts94gvCZF9BRo2a8/92d7Gej5FyAEiWPf0GGXXb19 wcDLerbdPMGPiRWhkyPOM3vVTbhAFBQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VTD61GWX; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf17.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.65 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704261916; a=rsa-sha256; cv=none; b=GPjXWjk+QT8bZjZUfvlQZZ1iz4BDUnbmFgksQME/kBXggeywzLgENChfPq2SVHgXcwxE4A 9I1t9DI/3JAXAoJN4JEH3a8529qm4d2tVN4T7mC8U7oOu8vG1Xwyn+XYl8Sk1MjhNB/ulA jB/FuziEfgvnI4xF3L7vbPsbq7utRQU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704261916; x=1735797916; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=SADNmv801L5zzCHLukWFMJZ5+gmmqGnOCeM/xTkND3M=; b=VTD61GWX2o+dDEs3ZN6zKFG7nZ0Sbq6THXXMoAEy3wSjZ6qoyXDZmT8S h3KgDgCmB7pJ36g3JSrLvxsVdqtNeQ/HB9WdZD7kJdSGsI4ZTM3Z1C2lj Z0Y7SXdTbckux5rhL47Dv0mSOd1mQM+zThg/h1tdsPt8csoXsGW3suKDt 8PX0TUoSHayrvOwmYxBWuSBYsaMCNJsN+AWxvlACNP9ifZY1K94v3lk3B OO9D391O458k6XsKn1a+eyf/xBLxSaTGoruA25FGxjgVqp38QsZaBhhRi 3uriOPRJ05Zeup+/MOOzq2H+HQVd4MvtBgyYfBnqzcA5vB9wcIzBn+AjO g==; X-IronPort-AV: E=McAfee;i="6600,9927,10941"; a="400770881" X-IronPort-AV: E=Sophos;i="6.04,327,1695711600"; d="scan'208";a="400770881" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jan 2024 22:05:14 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10941"; a="808732507" X-IronPort-AV: E=Sophos;i="6.04,327,1695711600"; d="scan'208";a="808732507" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jan 2024 22:05:07 -0800 From: "Huang, Ying" To: Gregory Price Cc: Gregory Price , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v5 01/11] mm/mempolicy: implement the sysfs-based weighted_interleave interface In-Reply-To: (Gregory Price's message of "Tue, 2 Jan 2024 21:59:48 -0500") References: <20231223181101.1954-1-gregory.price@memverge.com> <20231223181101.1954-2-gregory.price@memverge.com> <877cl0f8oo.fsf@yhuang6-desk2.ccr.corp.intel.com> <87h6jwdvxn.fsf@yhuang6-desk2.ccr.corp.intel.com> <87wmsrcexq.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 03 Jan 2024 14:03:09 +0800 Message-ID: <87il4bc5sy.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: E799840003 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ikyz5o17q1945o39t6j6zjdjy9dhgc7g X-HE-Tag: 1704261915-104990 X-HE-Meta: U2FsdGVkX1+AvAzPedQGuav1i13vTYECi1xcOUCJBxoHr3NChkUV6fPzK/NwUbwvNq9G5BIPm3paDYwjvByZpAPsiHOCDACAaLpvr+bY96re1WW0vRQdpJrLjvfD9xqAnYkzJ9b5pLHuPoMkdgoqgy4K9EdjOKht27gOpfgyC4czqLEvVepC+om27ZpTq3LvTUcfaxae+CPUG4A+Tn/AigKeLG9PHnIR/Xrlwv/eFzEP/pOJrpkveiFUUgrvM82rrOZPMqBhsinvLMUCv5dGPKWssN0ONigOCb1QOdP/7kDYJWWFTwF6bkpEBPejtsO3jsf+PMx9FvRcDocitC0yeymBqbl0kR3mz4tOwpyFovvVlonILXdo2N2t0o26foj0H6l9gROYXQ5SlG9RIgeJpq5AMppkd/Z19jvdsUSgVZPk8Zwp3N19sLjS9QMK4zncxCEKwI8c+AM4giYxTCFt7SgCl42GOMByy58sLTErdJeA1QRXCxL/lCF1/kf5tchlWXcrW6a49UlP4wRBd+kUY+0HfDCy4MnyGydiFpMMx48cCjOIZ7pXI8rT5faSomVSTQ3CRcaAOicHG3Gr/OZqB94hOy2XQwb77Ofc21TRfWRe8igzeV5AycEBpRMfb16unj0uFkwFqxlA86rM0e3O6JAspChsgEOdvBjcDnL/eoFs3rN5KuL7fSaM9C4JfzEtsGtXWHhQpov0wQA3zACYQwU4YbziTQ50lPwpGfW1uiROsppFb/RfDjIXxeild7B6XUYveCmP30OeSOAnIrFaoqCfafNN9zci2QRlY/qitRrMmw2NtCgFknVwddhJA+Pzw30RSYfRRQKuaW1EwmSOsEguSACfD7pazbN24t8/E6dyTT97jFWMDPtGv0NAp+f/3NKDeb9XYgONoeIIVnASOuJyrylYqIBD2DBQs06J0S4K4Y5mJFzlZ30XMbzwAeNqS6tODic4hFbwbX+rUoZ CwjoLHIG uQApdjTXN8C8B2zn9NoyWkkyGe5rkgcrci3SiBKBEmbcB+/0z1rExdtN4/zd7O0nGvZz4m8hP4anRhEtV+MKPdF4qTyWuMiw7+LtqRHSuHN3eJbNfeq72/BXeBPncMRJ+5YpwmpYOv4g9BnKWIbN4tNfNxRPoP7HyH4MD9xcOwQ7t2rpHjZzAZxKAPzN5c5Z4fS9f8hvFZZsCIFoPq3r3m0y010X8LahpUjQmo/WRuJPBxWERCilFDOvDfTiI1Lr2oa9MPgApBbbgCZk1TgevqkCmRw+0GLpPjcnAN7OjhP1r/aXR3I5SUa7jOlZpK1crCZuMk05ZOu6eqI8= 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: Gregory Price writes: > On Wed, Jan 03, 2024 at 10:45:53AM +0800, Huang, Ying wrote: >> >> > The minimum functionality is everything receiving a default weight of 1, >> > such that weighted interleave's behavior defaults to round-robin >> > interleave. This gets the system off the ground. >> >> I don't think that we need to implement all functionalities now. But, >> we may need to consider more especially if it may impact the user space >> interface. The default base weight is something like that. If we >> change the default base weight from "1" to "16" later, users may be >> surprised. So, I think it's better to discuss it now. >> > > This is a hill I don't particularly care to die on. I think the weights > are likely to end up being set at boot and rebalanced as (rare) hotplug > events occur. > > So if people think the default weight should be 3,16,24 or 123, i don't > think it's going to matter. > >> >> We can use a wrapper function to hide the logic. >> > > Done. I'll push a new set tomorrow. > >> > I think it also allows MPOL_F_GWEIGHT to be eliminated. >> >> Do we need a way to distinguish whether to copy the global weights to >> local weights when the memory policy is created? That is, when the >> global weights are changed later, will the changes be used? One >> possible solution is >> >> - If no weights are specified in set_mempolicy2(), the global weights >> will be used always. >> >> - If at least one weight is specified in set_mempolicy2(), it will be >> used, and the other weights in global weights will be copied to the >> local weights. That is, changes to the global weights will not be >> used. >> > > What's confusing about that is that if a user sets a weight to 0, > they'll get a non-0 weight - always. > > In my opinion, if we want to make '0' mean 'use system default', then > it should mean 'ALWAYS use system default for this node'. > > "Use the system default at the time the syscall was called, and do not > update to use a new system default if that default is changed" is > confusing. > > If you say use a global value, use the global value. Simple. I mainly have concerns about consistency. The global weights can be changed while the local weights are fixed. For example, - Weights of node 0,1 is [3, 1] initially - Process A call set_mempolicy2() to set weights to [4, 0], that is, use default weight for node 1. - After hotplug, the weights of node is changed to [12, 4, 1], now the effective weights used in process A becomes [4, 4]. Which is hardly desired. Another choice is to disallow "0" as weight in set_mempolicy2(). -- Best Regards, Huang, Ying