Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp625716imm; Tue, 5 Jun 2018 01:34:35 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJWivzhBgnTvZZt4SfjxzYxtw6v9BeldQw3ePvvPVbhprbrUhq7nnIWl7OGDsTYsSM27bJr X-Received: by 2002:a17:902:9a9:: with SMTP id 38-v6mr25888008pln.114.1528187675852; Tue, 05 Jun 2018 01:34:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528187675; cv=none; d=google.com; s=arc-20160816; b=qAFca26xO1VDZNg+g3Gn26sX4y++OM2HhS7YAXJ9qsKZLNt1vq4Hf6an0u92jngOD3 dgGvM0FNY2Qo7abWIsK915/kOnyS5LjvqAAiacEFB+o/VKFy8iHsrDfpxVFloqSXCwIE eXTc117ovKDuhcRf1zvwKdiSPXvWjKJOWIBe2zhMOIU5vROzQGlUhWaLOacBFGUWu4sg aU4Mdg59kouzkWgfyNq0mEqJKLBCL4BGXZ5izhosvHIbUaReAtD0vpjgw61cMsNbdDLj Q4igRkNyRFYgh4xXghJPjbtl7hmtIGMW98fyttBhXVVcVap4CzUWfXS3vRwigu/HQJFy 0z+w== 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:arc-authentication-results; bh=BsBdJBehp8JT23rBZ6+94F8Hseif/pA1Hpc5hQ3CBcg=; b=EyuWi/uoeFft8EIuvFIjWzja50b2N1ln6/WlBErhvjqbjkLdhMid/bLktLuDEDZDrV VSn1tYstir4eFrkcVvG/qBewtj1A2PUurq/47nIRBEk7k3WTGAEBkHjpSHITvQVNO8sn uLJEXC85iPj10JWxpUEFqGQxLcHVVbUfvFBePSrCtAITuM92kK9/8qlR9a+0JtGV0pPO xq2ho+CL6E/2GSYieZe0mOCkajXOwgPGXiqb55FD3cY0YBWsIZo6T9if+sz5H2IJ5Ci9 6YkBy/yuWq94dpcLTztRG0BAqz04CvzZgM6e4NdH4EQq19p7LvtS6LJS0tRGjXpQ1hbB B7Ww== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a11-v6si31598034plt.39.2018.06.05.01.34.21; Tue, 05 Jun 2018 01:34:35 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751507AbeFEIcr (ORCPT + 99 others); Tue, 5 Jun 2018 04:32:47 -0400 Received: from mx2.suse.de ([195.135.220.15]:47759 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751296AbeFEIcp (ORCPT ); Tue, 5 Jun 2018 04:32:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B0342AE85; Tue, 5 Jun 2018 08:32:43 +0000 (UTC) Date: Tue, 5 Jun 2018 10:32:41 +0200 From: Michal Hocko To: Eric Dumazet Cc: David Miller , qing.huang@oracle.com, tariqt@mellanox.com, haakon.bugge@oracle.com, yanjun.zhu@oracle.com, netdev@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, gi-oh.kim@profitbricks.com Subject: Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks Message-ID: <20180605083241.GU19202@dhcp22.suse.cz> References: <20180525.102321.858995452200286788.davem@davemloft.net> <7a353b65-6b7f-1aee-1c48-e83c8e02f693@gmail.com> <0e11e0fc-6ccf-aa93-9c4f-b9eae1b90643@gmail.com> <20180531065405.GH15278@dhcp22.suse.cz> <20180531085532.GK15278@dhcp22.suse.cz> <20180531091022.GL15278@dhcp22.suse.cz> <20180604131104.GS19202@dhcp22.suse.cz> <1908601f-2eda-d739-9c4d-430a002b1a05@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1908601f-2eda-d739-9c4d-430a002b1a05@gmail.com> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 04-06-18 06:22:26, Eric Dumazet wrote: > > > On 06/04/2018 06:11 AM, Michal Hocko wrote: > > On Thu 31-05-18 11:10:22, Michal Hocko wrote: > > > Just in case you are interested > > --- > > From 5010543ed6f73e4c00367801486dca8d5c63b2ce Mon Sep 17 00:00:00 2001 > > From: Michal Hocko > > Date: Mon, 4 Jun 2018 15:07:37 +0200 > > Subject: [PATCH] net: cleanup gfp mask in alloc_skb_with_frags > > > > alloc_skb_with_frags uses __GFP_NORETRY for non-sleeping allocations > > which is just a noop and a little bit confusing. > > > > __GFP_NORETRY was added by ed98df3361f0 ("net: use __GFP_NORETRY for > > high order allocations") to prevent from the OOM killer. Yet this was > > not enough because fb05e7a89f50 ("net: don't wait for order-3 page > > allocation") didn't want an excessive reclaim for non-costly orders > > so it made it completely NOWAIT while it preserved __GFP_NORETRY in > > place which is now redundant. > > > > Drop the pointless __GFP_NORETRY because this function is used as > > copy&paste source for other places. > > > > Signed-off-by: Michal Hocko > > --- > > Reviewed-by: Eric Dumazet Thanks! What is the proper process now? Should I resend or somebody can pick it up from this thread? -- Michal Hocko SUSE Labs