Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp596357ybb; Wed, 1 Apr 2020 06:16:07 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvvNo/8W32Vczjfk6eshAGJV8hZiVapzH7rmGaW/hMb42BrSiujts13rec7Ig4xJxt/YZr2 X-Received: by 2002:a9d:5e0d:: with SMTP id d13mr12822522oti.162.1585746967606; Wed, 01 Apr 2020 06:16:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585746967; cv=none; d=google.com; s=arc-20160816; b=SRG7VRDimMz9i+qYoelaMjbtKu9sKoVDBRxG/4ExaUdokYSvZkAHwdLp6wts3S4IAk nvUu9f2WLaJnAIDyM1kmkXrJ3rp6LAv8IaP8VYCne6LFdQASZwixi96GUzt0H+oe/pGL rbVCB3HiQ1sPC7eLA+Nog6+76w0+lhbJE96v2eLEUYYp2PwWSNSOjCb4rng3hXpr+w2/ 3rkoYytwjuP2wx/fQDpdQGZQKxArGxwOtpRb3fvre+S17Lt4Z2h6tU3HJ6s2BdGBAR9l G2U7+GDGgFKdD7HFsPg1RhcfnoKnOSG3TiG1OqGu5/S/FoayrfDTUP/dY/EkhSShlV4e R6UA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=dleikcWi8O/Dsy44caf8CqNhSAJIVQo/Jx6V9Esj5fc=; b=yRGzJTve1F8/TphCo3cd/jAe+tfJ8d0qFdvVMUmgxyYSXZNYLTZxrH4QhuF0Nb+k1w v5FubcvhT/RPbxRxtwL/5G9BQJGcGhcqo5isn1GjvDQEPY0mJhumBeTlfGKwlLhshE62 sPZaCjjxTnOceDeSJ3fyd8C/4y7KaVidRIY/uUxwxMXJH7thom0FIw5ZjhOKtxlyl3y+ COBNNxuU4yZwXlg+wr9r2iAo4RFlim6ugRZSJGT5sAqZvNxuiBkqNWVwZgLzkXYkuk2h GPi8hlagQqJEGOB3JjTKfUSYkqhldwl57j25FAZNVgEUxR3B44T/9wf5QfKLfxvk6bJX Unaw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w73si916792oiw.206.2020.04.01.06.15.48; Wed, 01 Apr 2020 06:16:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732632AbgDANOe (ORCPT + 99 others); Wed, 1 Apr 2020 09:14:34 -0400 Received: from mx2.suse.de ([195.135.220.15]:42172 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732252AbgDANOd (ORCPT ); Wed, 1 Apr 2020 09:14:33 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 87DBAABAE; Wed, 1 Apr 2020 13:14:31 +0000 (UTC) Date: Wed, 1 Apr 2020 14:14:26 +0100 From: Mel Gorman To: Michal Hocko Cc: Joel Fernandes , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rcu@vger.kernel.org, willy@infradead.org, peterz@infradead.org, neilb@suse.com, vbabka@suse.cz, Andrew Morton , Josh Triplett , Lai Jiangshan , Mathieu Desnoyers , "Paul E. McKenney" , Steven Rostedt Subject: Re: [PATCH RFC] rcu/tree: Use GFP_MEMALLOC for alloc memory to free memory pattern Message-ID: <20200401131426.GN3772@suse.de> References: <20200331131628.153118-1-joel@joelfernandes.org> <20200331145806.GB236678@google.com> <20200331153450.GM30449@dhcp22.suse.cz> <20200331160117.GA170994@google.com> <20200401072359.GC22681@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20200401072359.GC22681@dhcp22.suse.cz> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 01, 2020 at 09:23:59AM +0200, Michal Hocko wrote: > > Can you suggest what prevents other users of GFP_MEMALLOC from doing that > > also? > > There is no explicit mechanism which is indeed unfortunate. The only > user real user of the flag is Swap over NFS AFAIK. I have never dared to > look into details on how the complete reserves depletion is prevented. > Mel would be much better fit here. > It's "prevented" by the fact that every other memory allocation request that is not involved with reclaiming memory gets stalled in the allocator with only the swap subsystem making any progress until the machine recovers. Potentially only kswapd is still running until the system recovers if stressed hard enough. The naming is terrible but is mased on kswapd's use of the PF_MEMALLOC flag. For swap-over-nfs, GFP_MEMALLOC saying "this allocation request is potentially needed for kswapd to make forward progress and not freeze". I would not be comfortable with kfree_rcu() doing the same thing because there can be many callers in parallel and it's freeing slab objects. Swap over NFS should free at least one page, freeing a slab object is not guaranteed to free anything. -- Mel Gorman SUSE Labs