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 DE836C47258 for ; Wed, 31 Jan 2024 09:22:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4647F6B0074; Wed, 31 Jan 2024 04:22:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4149A6B0078; Wed, 31 Jan 2024 04:22:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DC746B007D; Wed, 31 Jan 2024 04:22:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1F5816B0074 for ; Wed, 31 Jan 2024 04:22:11 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C1B721A0454 for ; Wed, 31 Jan 2024 09:22:10 +0000 (UTC) X-FDA: 81739064820.09.545C977 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) by imf16.hostedemail.com (Postfix) with ESMTP id 42287180006 for ; Wed, 31 Jan 2024 09:22:06 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Wohi/Frx"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.13 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=1706692929; 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=qQ9tEr4YW1sl4QOEdLADkqv9jsTAisR2aLGCJeaidBM=; b=gGuIRsCoY6tkf0pGGndleryjfFfTjAF4Iwv/zAGkg2k3DPPL5CWWug6A32AGL91YYUJ2rv Ozt4sUXcSd+szxjkNI+0h7OUzuOaOe0Yaqp84UcdplACXjUS53XdcYBsOtpzn16JIbBrtQ CGe5VxMYYBMO48n7rW+I3y6CzkCBXdY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Wohi/Frx"; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.13 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706692929; a=rsa-sha256; cv=none; b=XBU+FUWaCPe9xYkxqQJZI2iPl3QsMbPQM0OzP8P/u2G8oCCvofj9I2b22PeuQEbxl1kfXE 1V1InrGsPUraxisSVHOLH4Luqn9xfrQhiYW5SwZWDoF4GrFkKFkm6UjlNvDBhZOo2q4XIz mW07gnqk82TMrNYZshHPXgugo7lQtig= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1706692927; x=1738228927; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=CIUpGUXPv7s5EVwneVuhL8R9G3KLULjDTGG/TKf9KI0=; b=Wohi/FrxDs8Yw8IVCJP877C7l70mB6IXxfzpTxQsRRncNWkrsxzmckIO 7hucbdRJQ72RB5VUtwJpNV+LbLL5jG9qZHTR0QfUi+sG0prPe5HPLCqlS cgCSa998yKOmK9ofOdrrMSCj1x9NmrtdhXYGAtK0DXiGXwzE3o7ZR/cNm UqkZlfWrzaUdno3VdwOejzNtCjUYWH2yLs4OBgPqatu09Y7CVBKiPpHVF Hp0GRlGh49HrNQDxwMtmcrjQJ/rxuSka88NLXrgwub1bnEpEs6dXzvOpl 6Lx5tiBAbMiS/JGprmhHDUHa++nfXxdIVo3zypXJ1iKUPO9MRo8TeQmqc Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10969"; a="2480956" X-IronPort-AV: E=Sophos;i="6.05,231,1701158400"; d="scan'208";a="2480956" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2024 01:21:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10969"; a="738034755" X-IronPort-AV: E=Sophos;i="6.05,231,1701158400"; d="scan'208";a="738034755" 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; 31 Jan 2024 01:21:47 -0800 From: "Huang, Ying" To: Gregory Price Cc: Gregory Price , , , , , , , , , , , , , , , , , , , , , Srinivasulu Thanneeru Subject: Re: [PATCH v4 3/3] mm/mempolicy: introduce MPOL_WEIGHTED_INTERLEAVE for weighted interleaving In-Reply-To: (Gregory Price's message of "Wed, 31 Jan 2024 02:43:16 -0500") References: <20240130182046.74278-1-gregory.price@memverge.com> <20240130182046.74278-4-gregory.price@memverge.com> <877cjqgfzz.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Wed, 31 Jan 2024 17:19:51 +0800 Message-ID: <87y1c5g8qw.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: 42287180006 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: xkpdt9wc15bqm5uqzomfac6agjzkon6s X-HE-Tag: 1706692926-861149 X-HE-Meta: U2FsdGVkX195XsP8VVKZAqjd0PfS0GXCruaxlXqvFmKjlB37OcGRRqh+xExxOEL1uZkpDVPUJGoarjJ5EZnS4UXs3XS2X4bL2um9/QPYH56118XDH0EpmCqnsf5FjNhc2pGT0Bl4Hzw7REe5S0ie5svyPqrDkeVa3XcDP64W7DbEyDeP4jtD/aLJRquG9FXv4/pIKQJlSPo+FRpCW86AauTjLbmJX97JsdA23NQkDUhflLpDIJoOB2livABpzY3HNoxpe6N9GBNpi9w399TXQgaTLixTEZIVVAnpJuZLi9m3aD1xLFaLxKvQUKxDkOWkHhZBiNzb1yCCq+emSEuEmdkIMXOJRatFOw9knXL5BQNmfh8rEns0wG4NUij/uJOLD97ifMZAhP0qGMp9E/xOJ+nrOvYNHb/MR1iJVKDPqDB41uXhYip8SVIQKcRH4EfUdPRLEEObFB7QAW6xHgYcSHdKCCRGSU0V72EcFg7YBI/t6bRe89dr6IXpc/Oovz+lGE4HIsxrgjjpzQL2gDcLRlZzh/S800nymRs5zipcmTlCm6yJqPLIQZexXgUbWiDnmDYz+BOzJ5f0A/c90KkTf8EMju09LaV2LpZ4/4Av4Q/aOk/90Eh5O0KDUSRvv+fWY4YrI+0hkn5m9l61UQCQsDEYB5xAfK7E9zgIbl15kr4u80sdaT6ar2Czh/ZTihStV/BZDSfXtYzeMo5z9q5YisRlbKKDboYGOMTu2CTdqUuMYZppTRtgsBrhuBLZ5URuAxSTOq3fEsduwu7XlS6pBbJWHkG45X1ULkuOgqrJQeg75O48rKiXBMjb5ZmfyKc+oilX4MOE6QY2TuZmjQ9ZufGwXpWdKVHBqOUIHqjdvyPM8BIA23nEcQv3ob85mB1oBL7wG+Ev3FgSXVAkdyI84akeJfF40EJektix8jnFum4BG5ri0H1yknORkeQdAGSstNVLafCi/lAGKcKVbr7 om6WaU52 DnEEEUZ0dA9py2+mRCHes7OAkHq0tIgYsIYL+FXTjRaFhXsHf8QVtnSYWNbPC32M7UCnX9a/TQZ0lMVbxbPLNzZZqBEvskl3aV8EgSak0dEFJNUkn5lkEd1NTpLte5Wsg8e/1SkPH9+kkt9uBtPYiiHeio4y+rTVAbZH2c0Lr7VIQ1ZGa7Thbh8k+v5qy0Il4MWy/gmgvnDN1puXp6vftMVARGdZkWchhqNeiF3nhQFZnH1jTwVJqgGGuUoAIbjhJEypGAMd56PbX7Cnry9GkBHqGIcAawUBi/dDluKkcwhXZnOoULbZv0MHjBCsQBxzuA1N0suN1MQ/gtYOaWr2zQlmzuxlhAVB9b3XH 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 31, 2024 at 02:43:12PM +0800, Huang, Ying wrote: >> Gregory Price writes: >> > >> > +static unsigned int weighted_interleave_nodes(struct mempolicy *policy) >> > +{ >> > + unsigned int node = current->il_prev; >> > + >> > + if (!current->il_weight || !node_isset(node, policy->nodes)) { >> > + node = next_node_in(node, policy->nodes); >> > + /* can only happen if nodemask is being rebound */ >> > + if (node == MAX_NUMNODES) >> > + return node; >> >> I feel a little unsafe to read policy->nodes at same time of writing in >> rebound. Is it better to use a seqlock to guarantee its consistency? >> It's unnecessary to be a part of this series though. >> > > I think this is handled already? It is definitely an explicit race > condition that is documented elsewhere: > > /* > * mpol_rebind_policy - Migrate a policy to a different set of nodes > * > * Per-vma policies are protected by mmap_lock. Allocations using per-task > * policies are protected by task->mems_allowed_seq to prevent a premature > * OOM/allocation failure due to parallel nodemask modification. > */ Thanks for pointing this out! If we use task->mems_allowed_seq reader side in weighted_interleave_nodes() we can guarantee the consistency of policy->nodes. That may be not deserved, because it's not a big deal to allocate 1 page in a wrong node. It makes more sense to do that in alloc_pages_bulk_array_weighted_interleave(), because a lot of pages may be allocated there. > example from slub: > > do { > cpuset_mems_cookie = read_mems_allowed_begin(); > zonelist = node_zonelist(mempolicy_slab_node(), pc->flags); > ... > } while (read_mems_allowed_retry(cpuset_mems_cookie)); > > quick perusal through other allocators, show similar checks. > > page_alloc.c - check_retry_cpusetset() > filemap.c - filemap_alloc_folio() > > If we ever want mempolicy to be swappable from outside the current task > context, this will have to change most likely - but that's another > feature for another day. > -- Best Regards, Huang, Ying