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 X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C1A0C433E0 for ; Wed, 10 Mar 2021 05:19:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D73FC64FEE for ; Wed, 10 Mar 2021 05:19:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D73FC64FEE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B34048D0169; Wed, 10 Mar 2021 00:19:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B0ACC8D0148; Wed, 10 Mar 2021 00:19:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9AAEE8D0169; Wed, 10 Mar 2021 00:19:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id 7EC4C8D0148 for ; Wed, 10 Mar 2021 00:19:56 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2BF78180AD801 for ; Wed, 10 Mar 2021 05:19:56 +0000 (UTC) X-FDA: 77902812792.01.BEC7555 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf09.hostedemail.com (Postfix) with ESMTP id 73B776000103 for ; Wed, 10 Mar 2021 05:19:52 +0000 (UTC) IronPort-SDR: x6MtCvEe7CNXnWQRCM0Yzl4Yof3InBF9JV4nkyOZGi6q+nvIjME7eyPvxXPpUU5KV5dY1feAMx AJNny6P3Ahlw== X-IronPort-AV: E=McAfee;i="6000,8403,9917"; a="175987197" X-IronPort-AV: E=Sophos;i="5.81,236,1610438400"; d="scan'208";a="175987197" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Mar 2021 21:19:52 -0800 IronPort-SDR: HjArI0DCgVD1LJhN/PbGPVNatw7uUI68n1NDXXKii5FoaVBJ4SDJRMYrxONeg2K27tGisNucgA se1DJbjn6tEg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,236,1610438400"; d="scan'208";a="431068445" Received: from shbuild999.sh.intel.com (HELO localhost) ([10.239.147.94]) by fmsmga004.fm.intel.com with ESMTP; 09 Mar 2021 21:19:48 -0800 Date: Wed, 10 Mar 2021 13:19:47 +0800 From: Feng Tang To: Dave Hansen , Michal Hocko , Ben Widawsky Cc: Michal Hocko , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Andrew Morton , Andrea Arcangeli , David Rientjes , Mel Gorman , Mike Kravetz , Randy Dunlap , Vlastimil Babka , Andi Kleen , "Williams, Dan J" Subject: Re: [PATCH v3 RFC 14/14] mm: speedup page alloc for MPOL_PREFERRED_MANY by adding a NO_SLOWPATH gfp bit Message-ID: <20210310051947.GA33036@shbuild999.sh.intel.com> References: <1614766858-90344-15-git-send-email-feng.tang@intel.com> <20210303120717.GA16736@shbuild999.sh.intel.com> <20210303121833.GB16736@shbuild999.sh.intel.com> <20210303131832.GB78458@shbuild999.sh.intel.com> <20210303134644.GC78458@shbuild999.sh.intel.com> <20210303163141.v5wu2sfo2zj2qqsw@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 73B776000103 X-Stat-Signature: z6sjsqwzr5box717sagnwrbou3iwqw7e Received-SPF: none (intel.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mga18.intel.com; client-ip=134.134.136.126 X-HE-DKIM-Result: none/none X-HE-Tag: 1615353592-875436 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: On Wed, Mar 03, 2021 at 08:48:58AM -0800, Dave Hansen wrote: > On 3/3/21 8:31 AM, Ben Widawsky wrote: > >> I haven't got to the whole series yet. The real question is whether the > >> first attempt to enforce the preferred mask is a general win. I would > >> argue that it resembles the existing single node preferred memory policy > >> because that one doesn't push heavily on the preferred node either. So > >> dropping just the direct reclaim mode makes some sense to me. > >> > >> IIRC this is something I was recommending in an early proposal of the > >> feature. > > My assumption [FWIW] is that the usecases we've outlined for multi-preferred > > would want more heavy pushing on the preference mask. However, maybe the uapi > > could dictate how hard to try/not try. > > There are two things that I think are important: > > 1. MPOL_PREFERRED_MANY fallback away from the preferred nodes should be > *temporary*, even in the face of the preferred set being full. That > means that _some_ reclaim needs to be done. Kicking off kswapd is > fine for this. > 2. MPOL_PREFERRED_MANY behavior should resemble MPOL_PREFERRED as > closely as possible. We're just going to confuse users if they set a > single node in a MPOL_PREFERRED_MANY mask and get different behavior > from MPOL_PREFERRED. > > While it would be nice, short-term, to steer MPOL_PREFERRED_MANY > behavior toward how we expect it to get used first, I think it's a > mistake if we do it at the cost of long-term divergence from MPOL_PREFERRED. Hi All, Based on the discussion, I update the patch as below, please review, thanks >From ea9e32fa8b6eff4a64d790b856e044adb30f04b5 Mon Sep 17 00:00:00 2001 From: Feng Tang Date: Wed, 10 Mar 2021 12:31:24 +0800 Subject: [PATCH] mm/mempolicy: speedup page alloc for MPOL_PREFERRED_MANY When doing broader test, we noticed allocation slowness in one test case that malloc memory with size which is slightly bigger than free memory of targeted nodes, but much less then the total free memory of system. The reason is the code enters the slowpath of __alloc_pages_nodemask(), which takes quite some time. Since alloc_pages_policy() will give it a 2nd try with NULL nodemask, we tried solution which creates a new gfp_mask bit __GFP_NO_SLOWPATH for explicitely skipping entering slowpath in the first try, which is brutal and costs one precious gfp mask bit. Based on discussion with Michal/Ben/Dave [1], only skip entering direct reclaim while still allowing it to wakeup kswapd, which can fix the slowness and make MPOL_PREFERRED_MANY more close to the semantic of MPOL_PREFERRED, while avoid creating a new gfp bit. [1]. https://lore.kernel.org/lkml/1614766858-90344-15-git-send-email-feng.tang@intel.com/ Suggested-by: Michal Hocko Signed-off-by: Feng Tang --- mm/mempolicy.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index d66c1c0..00b19f7 100644 --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -2205,9 +2205,13 @@ static struct page *alloc_pages_policy(struct mempolicy *pol, gfp_t gfp, * | MPOL_PREFERRED_MANY (round 2) | local | NULL | * +-------------------------------+---------------+------------+ */ - if (pol->mode == MPOL_PREFERRED_MANY) + if (pol->mode == MPOL_PREFERRED_MANY) { gfp_mask |= __GFP_RETRY_MAYFAIL | __GFP_NOWARN; + /* Skip direct reclaim, as there will be a second try */ + gfp_mask &= ~__GFP_DIRECT_RECLAIM; + } + page = __alloc_pages_nodemask(gfp_mask, order, policy_node(gfp, pol, preferred_nid), policy_nodemask(gfp, pol)); -- 2.7.4