From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by kanga.kvack.org (Postfix) with ESMTP id 743EC6B006E for ; Tue, 30 Jun 2015 19:49:28 -0400 (EDT) Received: by igrv9 with SMTP id v9so23697513igr.1 for ; Tue, 30 Jun 2015 16:49:27 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com. [2607:f8b0:4001:c03::234]) by mx.google.com with ESMTPS id zx8si47061igc.15.2015.06.30.16.49.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2015 16:49:27 -0700 (PDT) Received: by ieqy10 with SMTP id y10so23703543ieq.0 for ; Tue, 30 Jun 2015 16:49:27 -0700 (PDT) Date: Tue, 30 Jun 2015 16:49:25 -0700 (PDT) From: David Rientjes Subject: Re: [RFC V3] net: don't wait for order-3 page allocation In-Reply-To: <20150618154716.GH5858@dhcp22.suse.cz> Message-ID: References: <0099265406c32b9b9057de100404a4148d602cdd.1434066549.git.shli@fb.com> <557AA834.8070503@suse.cz> <20150618143019.GE5858@dhcp22.suse.cz> <20150618144311.GF5858@dhcp22.suse.cz> <5582E240.8080704@suse.cz> <20150618154716.GH5858@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Vlastimil Babka , Eric Dumazet , Shaohua Li , netdev , David Miller , kernel-team , clm@fb.com, linux-mm@kvack.org, dbavatar@gmail.com On Thu, 18 Jun 2015, Michal Hocko wrote: > That is to be discussed. Most allocations already express their interest > in memory reserves by __GFP_HIGH directly or by GFP_ATOMIC indirectly. > So maybe we do not need any additional flag here. There are not that > many ~__GFP_WAIT and most of them seem to require it _only_ because the > context doesn't allow for sleeping (e.g. to prevent from deadlocks). > We're talking about a patch that is being backported to stable. Regardless of what improvements can be made to specify that an allocation shouldn't be able to access reserves (and what belongs solely in the page allocator proper) independent of __GFP_NO_KSWAPD, that can be cleaned up at a later time. I don't anticipate that cleanup to be backported to stable, and my primary concern here is the ability for this allocations to now access, and possibly deplete, memory reserves. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Rientjes Subject: Re: [RFC V3] net: don't wait for order-3 page allocation Date: Tue, 30 Jun 2015 16:49:25 -0700 (PDT) Message-ID: References: <0099265406c32b9b9057de100404a4148d602cdd.1434066549.git.shli@fb.com> <557AA834.8070503@suse.cz> <20150618143019.GE5858@dhcp22.suse.cz> <20150618144311.GF5858@dhcp22.suse.cz> <5582E240.8080704@suse.cz> <20150618154716.GH5858@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Vlastimil Babka , Eric Dumazet , Shaohua Li , netdev , David Miller , kernel-team , clm@fb.com, linux-mm@kvack.org, dbavatar@gmail.com To: Michal Hocko Return-path: Received: from mail-ig0-f175.google.com ([209.85.213.175]:34979 "EHLO mail-ig0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752919AbbF3Xt2 (ORCPT ); Tue, 30 Jun 2015 19:49:28 -0400 Received: by igblr2 with SMTP id lr2so86419198igb.0 for ; Tue, 30 Jun 2015 16:49:27 -0700 (PDT) In-Reply-To: <20150618154716.GH5858@dhcp22.suse.cz> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 18 Jun 2015, Michal Hocko wrote: > That is to be discussed. Most allocations already express their interest > in memory reserves by __GFP_HIGH directly or by GFP_ATOMIC indirectly. > So maybe we do not need any additional flag here. There are not that > many ~__GFP_WAIT and most of them seem to require it _only_ because the > context doesn't allow for sleeping (e.g. to prevent from deadlocks). > We're talking about a patch that is being backported to stable. Regardless of what improvements can be made to specify that an allocation shouldn't be able to access reserves (and what belongs solely in the page allocator proper) independent of __GFP_NO_KSWAPD, that can be cleaned up at a later time. I don't anticipate that cleanup to be backported to stable, and my primary concern here is the ability for this allocations to now access, and possibly deplete, memory reserves.