Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp375565imm; Thu, 31 May 2018 01:58:24 -0700 (PDT) X-Google-Smtp-Source: ADUXVKK9Vky8QV9dynUXl2kQo0J9OyKfetVTg76YlvYF48QR5BMOKZTUE67iJ5dEaWDugEJDwhEj X-Received: by 2002:a62:81c5:: with SMTP id t188-v6mr1543094pfd.146.1527757103967; Thu, 31 May 2018 01:58:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527757103; cv=none; d=google.com; s=arc-20160816; b=AQgUjswmMh+f57ipWSY248VykXzC4gdJ1Gm8hdibDBA1mSJUwBfyUF0NFResa00gnY y9nIJecdfh7/7NvZLHXXaNeWWo3HlY6m+wavxpSYlmAZG1z4G+PVxQfZzzsW5t/Udjh9 FLhhlpi8yz4YHcK3AyS5MCFLpXo2SOh7YcrQ38E2NwNWEJoJf9goe3AIgKhN1tZJMxvu OC0GLmobWFlFLxOkMNM3NZWvMEhMZ2yYLFSem7f1nbBju7INIrpLrR4nBLVGnf9UwmOu 2T8AblcJ9xP3KH1QrhoihWpli+iZ/E5frm003NTi//d9MhkH8UiA/L+c+hj8HgyGBBdX 0eXw== 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=jFxjpVBHLcWwkIP7Umlw3ikCndCM9jm6j1HIhv970aw=; b=nFO5Wkgj3py/BOn5E0TAzixBWaAqaRhqPfcFH6LnIZK0wjgF8GoCQs8Gde9NI2RWKQ 5m8Ff4Pv0XGFKR7TCq/8FgwLmHutxZk8cewqss86p2d1VlyjvBjzrOLwR/UjvXWRhVFl zqVSYmxkCgXg9IalL5Tv9PrcxT1EdDFloZEu0d/9DOmQ7CHdMPPh4V/cx8ZRJ0in9iPM lYNjTVxqtzxaPObzQH5a8UvVnA/qBAVHTzwk1w5wMLCXp4NJeButqW+VdHL6SIvAGyyu Kfm9wW65cebaXtzK5+3ltgHK+UrEAQ3nA/uyFej6/hROmKXKdb0/b3Fhs13jefN2ZqkQ nEsg== 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 k14-v6si14013849pgn.99.2018.05.31.01.58.09; Thu, 31 May 2018 01:58:23 -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 S1754232AbeEaIz5 (ORCPT + 99 others); Thu, 31 May 2018 04:55:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:59656 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754040AbeEaIzf (ORCPT ); Thu, 31 May 2018 04:55:35 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id ACF19ACA1; Thu, 31 May 2018 08:55:33 +0000 (UTC) Date: Thu, 31 May 2018 10:55:32 +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: <20180531085532.GK15278@dhcp22.suse.cz> References: <20180523232246.20445-1-qing.huang@oracle.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu 31-05-18 04:35:31, Eric Dumazet wrote: > > > On 05/31/2018 02:54 AM, Michal Hocko wrote: > > On Tue 29-05-18 23:49:59, Eric Dumazet wrote: > >> > >> > >> On 05/29/2018 11:44 PM, Eric Dumazet wrote: > >> > >>> > >>> And I will add this simple fix, this really should address your initial concern much better. > >>> > >>> @@ -99,6 +100,8 @@ static int mlx4_alloc_icm_pages(struct scatterlist *mem, int order, > >>> { > >>> struct page *page; > >>> > >>> + if (order) > >>> + gfp_mask |= __GFP_NORETRY; > >> > >> and also gfp_mask &= ~__GFP_DIRECT_RECLAIM > > > > JFTR the latter one makes __GFP_NORETRY pointless. Non sleeping allocations > > are not retrying. > > Hi Michal > > Since when this rule is applied ? Well, this has been the case since I remember. ~__GFP_DIRECT_RECLAIM resp. GFP_NOWAIT formerly meant that the allocation doesn't perform _any_ reclaim and therefore it never retries. Why would it? Any retry would just hope for a reclaim on behalf of somebody else. __GFP_NORETRY has always simply stopped retrying after one/few reclaim attempts. Implementation has changed here and there over time but in essence the semantic remained the same. Please have a look at the current documentation in gfp.h file and let me know if you would like some clarfications. > These GFP flags change all the time, I suggest mm experts to cleanup existing call sites ? Do you have any specific areas to look at? > I merely copied/pasted from alloc_skb_with_frags() :/ I will have a look at it. Thanks! -- Michal Hocko SUSE Labs