Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp361690imm; Thu, 31 May 2018 01:36:22 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJgcCrySK05HlwDRxj6d9Kr37z7gLHZZhuwPdpqW382yZ9ykH7OSL68/l+S5+NtzvaRffYe X-Received: by 2002:a17:902:4303:: with SMTP id i3-v6mr6258821pld.394.1527755782830; Thu, 31 May 2018 01:36:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527755782; cv=none; d=google.com; s=arc-20160816; b=KELoUNjnWaKrqVFnrX/+xwkqBtopURGA97XKytDfTPqseiHdHqpXu6yRSFlMxr1rQN FNZUYcishdz0Tns7geDCQ+roN0eJYKu4mbrxVp6Gpxqw09XkpLqMEuq6vnPq1bhWITB6 zE+Rwe51mnn+N2zzQ7RU9m0zC+4kzeDluHydEYRvEBd20IxGc8swZmlBpKC6O8R6sJxz uTxl+KNluvcXsHGWcG4WlMZlGSqcmy69287eXjLygLI3+Rfgb7PzoueEhJW344354LtQ tnfGuOlYWfa+SbJzWEwvd4zu13GEPkuGOwrhTqaG/oL8fDBhOerdX5+29CUtgkTC0eQF ufsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=ifcpGBUU8DULftfyiZjmTVv1aSOlCt5jI2WV04U08EQ=; b=nlg42+eS2Hy656cMaUdW8/p92/iDKLjzu9/X58VBj5K8FVlNGcNfFTo4Mjpwx+5N/a lbk15xauPW151yYHpTk9YsrPfGFyd1vc95yGT579ucPl2FTO8rEWo7+7YL4ftM9d6eVl iRRJ5BiGF+afp5TGbvXUjd1a5tY4DZ7SIuo4jOdfwDsspYsU20pbZ9lVkjub76iqNDki 3mr+rQuILlwoRfIKmI1Ksek4fKeWRtt/sJE10PsxqKhB2lDjN46u5w+xldHzIJ2uZQkn jIbicIaFCCHc6nLD89NJK2Ry6eaGj+Ul3RS4yZXIGhUx12BlqV5nBWdUzNCD0ZknuHf8 h57A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gUJrirWf; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x1-v6si35160264pfm.32.2018.05.31.01.36.08; Thu, 31 May 2018 01:36:22 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gUJrirWf; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754114AbeEaIfj (ORCPT + 99 others); Thu, 31 May 2018 04:35:39 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:36430 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754034AbeEaIff (ORCPT ); Thu, 31 May 2018 04:35:35 -0400 Received: by mail-pl0-f67.google.com with SMTP id v24-v6so12806589plo.3; Thu, 31 May 2018 01:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ifcpGBUU8DULftfyiZjmTVv1aSOlCt5jI2WV04U08EQ=; b=gUJrirWfzPHRFFmurmJL5BMpOJaHtfgNqxTddXeDH44l6NDea+ydsjPsYudaArb5wI HR2RuVsc3P0bJPoeOCmsEB5zwdD+/I270k64UEDW2Cak9oWKHDFUV5ptSKyfWcqwHD1P M04gi+8+lX+40vZI5AKIJ7/T52IDtZYtRRlAps48lzfpYdW0pT4PvsgWgQ9HZIG808fa mfgmHkmOuwgeY1VB2Vt0WiMzcMHf8hfJxsP1+ix+P+qkBIMUUuuV8tgSQ89oM50niRks 3NY7sFYZ3n6Mnod8ZiP1hez46fkcXzVa6g++aojrwKA80DQNGMMfhHB8NmXq9lyFVuHI LJFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ifcpGBUU8DULftfyiZjmTVv1aSOlCt5jI2WV04U08EQ=; b=kSN2PZK9B/wka2t5dRYVSI2TRxELklupPFK4SOXmewLwHdqK13aY4Xum/ZDvTfmVUX 9ZDIELLvYPMvZ03PXMQIbseHmTKFpInhL4anG1RxseLkvEXvKBmYr8sIoou7Sg8xk8XM qK2nOsI0StZTLoKVQqLo+nIEmmBNtT5y3cqSsVXu6c6qxi4qvVJp1FIvHsciVSsChjPD gV19d7A0ds4HVfsdZWxhJaP/qkxP0IXGMEQUwKgK0iBo+V2ysx18k+g9MXJfWjDfCZyK UjuCyCnHrIS5cTcS97vuVfX42/VspSuLDh1a27WbF5mRBnJjrrzifTSWHOROiMQCwi/6 J3vw== X-Gm-Message-State: ALKqPwdrc2Zw86AFZF+G7oTyYRJZeHYvxVKkc3fsXd6Dts6ES7/7oWpK IlUBppAh6vPMO0gLaFtAeLw= X-Received: by 2002:a17:902:a586:: with SMTP id az6-v6mr6151425plb.210.1527755735168; Thu, 31 May 2018 01:35:35 -0700 (PDT) Received: from [10.246.221.134] ([50.234.174.228]) by smtp.gmail.com with ESMTPSA id p24-v6sm75592254pfk.58.2018.05.31.01.35.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 01:35:34 -0700 (PDT) Subject: Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks To: Michal Hocko , 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 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> From: Eric Dumazet Message-ID: Date: Thu, 31 May 2018 04:35:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180531065405.GH15278@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ? These GFP flags change all the time, I suggest mm experts to cleanup existing call sites ? I merely copied/pasted from alloc_skb_with_frags() :/ Thanks !