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 76782C47258 for ; Wed, 24 Jan 2024 01:53:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CBDED6B0074; Tue, 23 Jan 2024 20:53:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C6E1A6B0075; Tue, 23 Jan 2024 20:53:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B0EF16B007B; Tue, 23 Jan 2024 20:53:29 -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 9BA436B0074 for ; Tue, 23 Jan 2024 20:53:29 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 48F121A02B8 for ; Wed, 24 Jan 2024 01:53:29 +0000 (UTC) X-FDA: 81712532538.29.52E11C2 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by imf07.hostedemail.com (Postfix) with ESMTP id 08A404000E for ; Wed, 24 Jan 2024 01:53:24 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mkF8tY6k; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf07.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.10 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=1706061206; 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=40DcXT/4Da6R5WOZUp2sGnIjAXMQq71yLt+/AqMrD3E=; b=Y0IFdIhMlW778GKuW1ErXr9xgxHxyhxL46b2YbiH4WWlB2b9mELxLQ1qp3BINuCLLtQePI KkRz2Na5FLyCDTgYAlQmGAQhM2PWCCvAxxI00XKAELgjCAtE2NOYZZzrkLR9bGSE94poHF e6kFgfl21wtCjtz1sKynZuhP8tMlOyw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mkF8tY6k; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf07.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706061206; a=rsa-sha256; cv=none; b=uxyFyv191QcI4idjAwBbjssxUGR46/iFIEaO52zUnSvbVNypZC3V4UA8FgPz4JVZErGeuL iRm2C4Bjl/nMKp/AM0llc5OGt7IhmuYMCvtB96TKmeJuOLV1DLixV523h5VYYtxGuG5yB8 PfqxAl4W1tjQYn82XaaRGhRfYqsZw7A= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706061205; x=1737597205; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=6anV9bsED/SQ83dHNmfrmB1sPazrK8p7SLusz+eOn4Q=; b=mkF8tY6kXhBA4rmMuxP2coiDvD99jJBJLm2CjCeOzWJpN5GbnTqQYLYl SJ6VaHFpRW2eFmkGZPAGpsZA310CB9n+RYPXWBMKj8Utvxsv7cNWiELqi GXDL6wHUtvTu0ggikyvPzbZ546VjcWIBiJwDlwuxjzm3GP29xYyYevE0J WU/x1nnN7lqn1mmOVcFo+A+1xC3Y9XZLbYjTx9EO3UZPI8Kq8uqsuLgbP R7ds2DlwQy/9dqewnGYlthWLhkiva0jnYZOQK6HWodkRNo4TcWeBQWtZd BtyejV6DSuLbsQ74EJzoaPps6ELHo7NMb8qSBg6bHZFWLNfzKo4Fk+0Qd g==; X-IronPort-AV: E=McAfee;i="6600,9927,10962"; a="9101882" X-IronPort-AV: E=Sophos;i="6.05,215,1701158400"; d="scan'208";a="9101882" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jan 2024 17:53:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10962"; a="735757106" X-IronPort-AV: E=Sophos;i="6.05,215,1701158400"; d="scan'208";a="735757106" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jan 2024 17:53:17 -0800 From: "Huang, Ying" To: Gregory Price Cc: Gregory Price , , , , , , , , , , , , , , , , , , , , , Srinivasulu Thanneeru Subject: Re: [PATCH v2 3/3] mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving In-Reply-To: (Gregory Price's message of "Tue, 23 Jan 2024 16:27:35 -0500") References: <20240119175730.15484-1-gregory.price@memverge.com> <20240119175730.15484-4-gregory.price@memverge.com> <87jzo0vjkk.fsf@yhuang6-desk2.ccr.corp.intel.com> <87a5owv454.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 24 Jan 2024 09:51:20 +0800 Message-ID: <87jznzts6f.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: 08A404000E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: hjqws1h7ypjiaj8ekegg3pumkgpzat31 X-HE-Tag: 1706061204-866870 X-HE-Meta: U2FsdGVkX1+DRFm41I0wUiNLDApyOBJQpcspmlbOUJjHMFHmdoJLyyVzwhQ0KTspdfnJPyvB37Nk/y8gwbk52FKl0j5NLr990vHuCU16b2HHehEV0E92vVXCP6TthUf/4WAKYmsWN/XnfTAMK64Q6tzdqi+eym8fLKAhZmWCAYTsRsu3bPbAyXFN2xDua3MJsE6iik+Se6e5NmuF41lydA6oaNFDUTzNRhxbIcBH4EQ/p6eTUiYWjC3MV3szmZzhADlYwIjtYpSiYVw+enSHYwAUGOrv7zp4S8VXvX555y96BbgL1izBJaBBX3OgHAOeF5gGL/3eemLCJEdOI4EhUDwzPCfkSYHUv94Lfk4gh9MKHdfzo7TN8j+JmU4gDKiHfTIEihjAJBMJgHa/AdTK1EQrnGdj/K3+FlHRZtmJ27sxu662OgWf0WcX5Yev7iHCPWi1QJmUXCpA4wAmCEZ1il6QrLh7Nf+WV9dvqjpUo1zVUYkhe7TIRz3+jIhUD5obTQQCPTRYBavfPCevrLNolrk0aLx44dNH513T859By+glgtsi9tke1fX1R7WAvxePylcQ5Q2+jdhlG0tl6DzeJLpzZS0pEdNkQDc1BbaSAJZrbGlgi4t7IVW02osbwMin1bNt5iyqivnVXjvl1dDgWVnAF22O1lsTUXPHtS1m8EefDwiSi91kRtoaFdQ6D00zrYUcDcaM5RAfO2LJmgkxNXmAMJ0tUtgDb0LrIT4qdBqfEAiKkuLshviWqIYIV3F/n+SDvfYlpfWaSzombhb15EXgwmpRC83ls6HzzLcwSg5MPZxDafFEpZZ7jYll7bdQqwRdIWHYZvo5+DZWfilo7bSKCfevRNYaTIInZcbV+WDZBHG2w1UXJ5waIahV2AMPeisXYN4XcUYYFrfRj9fuiotJhfx57UnYnfLdV9SE73Wk42UrxfjaqtdhARDXZm34UBDNYss73YUsQqA6s27 t4AEl1pR XVobHhDo0me6AcWQmznj88PBrIib7+K/3/2816zp0egvhzFH8Cp7e5tfKMnAe/p2RWJSh+3HyJsdMgqraUsZ3bkyvV3rokEXQ/E5i8uxmiuUHFN3IBcFKufwU3ncc1BnxvtdtyRHXGpn+Awx7x7uJY7415e2jTNNIKslWrAVB+dlLC6TqclMxI0vUGbVivjughuPdWaG3zFb6MJEBTrOHPKJjliIBEVHIigIiT4bDHnuz2KiwocOtJAq41UwtMVqMR5u1nx1G61xZpqrNc3N7aED2tpUKxc/og6SEuJBgsgLGf8pgMSo2EzVO5wBYlJ/JtSW4OKrecYqcGzE= 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 Tue, Jan 23, 2024 at 04:35:19PM +0800, Huang, Ying wrote: >> Gregory Price writes: >> >> > On Mon, Jan 22, 2024 at 11:54:34PM -0500, Gregory Price wrote: >> >> > >> >> > Can the above code be simplified as something like below? >> >> > >> >> > resume_node = prev_node; >> > --- resume_weight = 0; >> > +++ resume_weight = weights[node]; >> >> > for (...) { >> >> > ... >> >> > } >> >> > >> >> >> >> I'll take another look at it, but this logic is annoying because of the >> >> corner case: me->il_prev can be NUMA_NO_NODE or an actual numa node. >> >> >> > >> > After a quick look, as long as no one objects to (me->il_prev) remaining >> > NUMA_NO_NODE >> >> MAX_NUMNODES-1 ? >> > > When setting a new policy, the il_prev gets set to NUMA_NO_NODE. It's IIUC, it is set to MAX_NUMNODES-1 as below, @@ -846,7 +858,8 @@ static long do_set_mempolicy(unsigned short mode, unsigned short flags, old = current->mempolicy; current->mempolicy = new; - if (new && new->mode == MPOL_INTERLEAVE) + if (new && (new->mode == MPOL_INTERLEAVE || + new->mode == MPOL_WEIGHTED_INTERLEAVE)) current->il_prev = MAX_NUMNODES-1; task_unlock(current); mpol_put(old); I don't think we need to change this. > not harmful and is just (-1), which is functionally the same as > (MAX_NUMNODES-1) for the purpose of iterating the nodemask with > next_node_in(). So it's fine to set (resume_node = me->il_prev) > as discussed. > > I have a cleaned up function I'll push when i fix up a few other spots. > >> > while having a weight assigned to pol->wil.cur_weight, >> >> I think that it is OK. >> >> And, IIUC, pol->wil.cur_weight can be 0, as in >> weighted_interleave_nodes(), if it's 0, it will be assigned to default >> weight for the node. >> > > cur_weight is different than the global weights. cur_weight tells us > how many pages are remaining to allocate for the current node. > > (cur_weight = 0) can happen in two scenarios: > - initial setting of mempolicy (NUMA_NO_NODE w/ cur_weight=0) > - weighted_interleave_nodes decrements it down to 0 > > Now that i'm looking at it - the second condition should not exist, and > we can eliminate it. The logic in weighted_interleave_nodes is actually > annoyingly unclear at the moment, so I'm going to re-factor it a bit to > be more explicit. I am OK with either way. Just a reminder, the first condition may be true in alloc_pages_bulk_array_weighted_interleave() and perhaps some other places. -- Best Regards, Huang, Ying