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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 5D05FC433E0 for ; Wed, 3 Mar 2021 14:00:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 70EBA64EAE for ; Wed, 3 Mar 2021 14:00:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 70EBA64EAE Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DDE7C8D016C; Wed, 3 Mar 2021 09:00:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D8E778D0157; Wed, 3 Mar 2021 09:00:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2EEB8D016C; Wed, 3 Mar 2021 09:00:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0101.hostedemail.com [216.40.44.101]) by kanga.kvack.org (Postfix) with ESMTP id A820B8D0157 for ; Wed, 3 Mar 2021 09:00:38 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 53642513 for ; Wed, 3 Mar 2021 14:00:38 +0000 (UTC) X-FDA: 77878723356.17.B0F5C00 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf15.hostedemail.com (Postfix) with ESMTP id 912F9A001A96 for ; Wed, 3 Mar 2021 13:59:37 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1614779976; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=50GBfYgxtO29whyJbj1CWzLmypSM5EAt7Qtbs+R82zA=; b=PBaSKQadWq06jmGeraLw5vIaXnGXOlRSVL/6Vzl4kBb+nQhF4nFgv2izar18P7t3mCKFIl 42YmoDwsBmONbHnKqmbrq4gDNZ/AtarliFxTq4pO3bV/fAjC8ovDAVbunyUnVU7usYX/tG cWPkrP50tvhEm/JVDwBXSvsNb7Ks3cI= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3BBC0AE05; Wed, 3 Mar 2021 13:59:36 +0000 (UTC) Date: Wed, 3 Mar 2021 14:59:35 +0100 From: Michal Hocko To: Feng Tang Cc: "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Andrew Morton , Andrea Arcangeli , David Rientjes , Mel Gorman , Mike Kravetz , Randy Dunlap , Vlastimil Babka , "Hansen, Dave" , "Widawsky, Ben" , Andi leen , "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: References: <1614766858-90344-1-git-send-email-feng.tang@intel.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210303134644.GC78458@shbuild999.sh.intel.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 912F9A001A96 X-Stat-Signature: b39nd6rbqi6sxjhas9mp885khpaxc1uc Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614779977-131713 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 03-03-21 21:46:44, Feng Tang wrote: > On Wed, Mar 03, 2021 at 09:18:32PM +0800, Tang, Feng wrote: > > On Wed, Mar 03, 2021 at 01:32:11PM +0100, Michal Hocko wrote: > > > On Wed 03-03-21 20:18:33, Feng Tang wrote: [...] > > > > One thing I tried which can fix the slowness is: > > > > > > > > + gfp_mask &= ~(__GFP_DIRECT_RECLAIM | __GFP_KSWAPD_RECLAIM); > > > > > > > > which explicitly clears the 2 kinds of reclaim. And I thought it's too > > > > hacky and didn't mention it in the commit log. > > > > > > Clearing __GFP_DIRECT_RECLAIM would be the right way to achieve > > > GFP_NOWAIT semantic. Why would you want to exclude kswapd as well? > > > > When I tried gfp_mask &= ~__GFP_DIRECT_RECLAIM, the slowness couldn't > > be fixed. > > I just double checked by rerun the test, 'gfp_mask &= ~__GFP_DIRECT_RECLAIM' > can also accelerate the allocation much! though is still a little slower than > this patch. Seems I've messed some of the tries, and sorry for the confusion! > > Could this be used as the solution? or the adding another fallback_nodemask way? > but the latter will change the current API quite a bit. 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. -- Michal Hocko SUSE Labs