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=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 CB5ECC5DF62 for ; Wed, 6 Nov 2019 07:35:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 87DBA2173E for ; Wed, 6 Nov 2019 07:35:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 87DBA2173E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 43C416B0006; Wed, 6 Nov 2019 02:35:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3ECBC6B0007; Wed, 6 Nov 2019 02:35:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 303066B0008; Wed, 6 Nov 2019 02:35:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id 1A5C96B0006 for ; Wed, 6 Nov 2019 02:35:25 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id BD6392826 for ; Wed, 6 Nov 2019 07:35:24 +0000 (UTC) X-FDA: 76125042168.17.year98_696a83f476a4d X-HE-Tag: year98_696a83f476a4d X-Filterd-Recvd-Size: 3795 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Nov 2019 07:35:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 8E059AE3F; Wed, 6 Nov 2019 07:35:22 +0000 (UTC) Date: Wed, 6 Nov 2019 08:35:21 +0100 From: Michal Hocko To: David Rientjes Cc: Andrew Morton , Vlastimil Babka , Linus Torvalds , Andrea Arcangeli , Mel Gorman , "Kirill A. Shutemov" , Linux Kernel Mailing List , Linux-MM Subject: Re: [patch for-5.3 0/4] revert immediate fallback to remote hugepages Message-ID: <20191106073521.GC8314@dhcp22.suse.cz> References: <20191001083743.GC15624@dhcp22.suse.cz> <20191018141550.GS5017@dhcp22.suse.cz> <53c4a6ca-a4d0-0862-8744-f999b17d82d8@suse.cz> <08a3f4dd-c3ce-0009-86c5-9ee51aba8557@suse.cz> <20191029151549.GO31513@dhcp22.suse.cz> <20191029143351.95f781f09a9fbf254163d728@linux-foundation.org> <20191105130253.GO22672@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 Tue 05-11-19 17:01:00, David Rientjes wrote: > On Tue, 5 Nov 2019, Michal Hocko wrote: > > > > > Thanks, I'll queue this for some more testing. At some point we should > > > > decide on a suitable set of Fixes: tags and a backporting strategy, if any? > > > > > > > > > > I'd strongly suggest that Andrea test this patch out on his workload on > > > hosts where all nodes are low on memory because based on my understanding > > > of his reported issue this would result in swap storms reemerging but > > > worse this time because they wouldn't be constrained only locally. (This > > > patch causes us to no longer circumvent excessive reclaim when using > > > MADV_HUGEPAGE.) > > > > Could you be more specific on why this would be the case? My testing is > > doesn't show any such signs and I am effectivelly testing memory low > > situation. The amount of reclaimed memory matches the amount of > > requested memory. > > > > The follow-up allocation in alloc_pages_vma() would no longer use > __GFP_NORETRY and there is no special handling to avoid swap storms in the > page allocator anymore as a result of this patch. Yes there is no __GFP_NORETRY in the fallback path because the control over how hard to retry is controlled by alloc_hugepage_direct_gfpmask depending on the defrag mode and madvise mode. > I don't see any > indication that this allocation would behave any different than the code > that Andrea experienced swap storms with, but now worse if remote memory > is in the same state local memory is when he's using __GFP_THISNODE. The primary reason for the extensive swapping was exactly the __GFP_THISNODE in conjunction with an unbounded direct reclaim AFAIR. The whole point of the Vlastimil's patch is to have an optimistic local node allocation first and the full gfp context one in the fallback path. If our full gfp context doesn't really work well then we can revisit that of course but that should happen at alloc_hugepage_direct_gfpmask level. -- Michal Hocko SUSE Labs