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=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 16CDEC5DF60 for ; Wed, 6 Nov 2019 01:01:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D84D2087E for ; Wed, 6 Nov 2019 01:01:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="bAnOaztF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D84D2087E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 082856B0003; Tue, 5 Nov 2019 20:01:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 032826B0005; Tue, 5 Nov 2019 20:01:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E64766B0007; Tue, 5 Nov 2019 20:01:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) by kanga.kvack.org (Postfix) with ESMTP id CD3D76B0003 for ; Tue, 5 Nov 2019 20:01:04 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 80CBE4820 for ; Wed, 6 Nov 2019 01:01:04 +0000 (UTC) X-FDA: 76124048448.01.judge37_955e8e482617 X-HE-Tag: judge37_955e8e482617 X-Filterd-Recvd-Size: 5078 Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Nov 2019 01:01:04 +0000 (UTC) Received: by mail-pf1-f195.google.com with SMTP id c13so17477642pfp.5 for ; Tue, 05 Nov 2019 17:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=Txbd1n3WXZhvsgvEStK+7JvEW+gNhvfRDKuQjrimagg=; b=bAnOaztFbWE11f3TZekaIQrRKnaPMyTRlYFpZE+okZwn+QrBbdHAKH2ETQBNvxGC8C fPGhjhNCmDQ57/Ahb0Ege84BGpJ1Fcy6wF89RbGKmxma+d8WXt9ToPgYWi6RQTPG3hZ/ x4QmYNZYL169QiRIHBXisIegP2q0myfbur26HDTg+HciPsMXJl+7IcCgADTOooaMer42 UJ2kOO4YjXQPWztZLpQlpExB2aMVycXlHoRVdui9RExKfSRcc7DkXsOi8MRMWv3ZE5OQ st3cSzg5JNOFEeMjtFYuRnxuy8CnPNUb1lW8tiYL2+wsbxF6qYOeftHzwQhPI5Z2Q2xL rNBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=Txbd1n3WXZhvsgvEStK+7JvEW+gNhvfRDKuQjrimagg=; b=KYdvhdW9jKl//dyGcUJopftfwJayVl6lOyWUn9LNmQk3FF0m0TUNSp6WnhcrJS4mwt SGdaizYpdLCXYPbFEFrkiCMjN1WAy/RKif1aKM2lkx1XPfm0IKVwUvWRVFs2subLdako 0kldv5jnfZEg0z6+RdoNdc8lrvKDDUDoqher9x2oHRhU5cENY896DUrZzky8sk8KcZXs QK0OB0Didi5opvshMkfK2PnaxfcVFMDwwK8+s+rIH4yjVWYeT2ei1nplTxzsSnXNQm3W xyoy97lqSp+indzZKFOzb2It0QbdBt3ITVGuBvs0nCs5C7IQFyCRKMKOI5lkHv8yzRuD VMFA== X-Gm-Message-State: APjAAAX+JXL0wh3eVoeMYb+Hdnhr6tzlFiLjRt/wFC3/ReeEKUpHmfXq kaP909ccC06H3F8xPj+OtaY5sw== X-Google-Smtp-Source: APXvYqx9BUuMVoesQnq7M7zvoWtfFvSxkRRjqLW5cAtjA1k5ivCd6zrmcr9aY0mtelj+Oda/p8qjwA== X-Received: by 2002:a62:5801:: with SMTP id m1mr42129991pfb.204.1573002062623; Tue, 05 Nov 2019 17:01:02 -0800 (PST) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id z21sm19899398pfa.119.2019.11.05.17.01.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Nov 2019 17:01:01 -0800 (PST) Date: Tue, 5 Nov 2019 17:01:00 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Michal Hocko 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 In-Reply-To: <20191105130253.GO22672@dhcp22.suse.cz> Message-ID: References: <20190930112817.GC15942@dhcp22.suse.cz> <20191001054343.GA15624@dhcp22.suse.cz> <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> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. 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.