Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4723244imm; Wed, 30 May 2018 10:40:09 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKhYMYw4Kxm1lLn7P6Lz9vPw7DjswQdOBZaRvdJs9/LHmssZhQKi3KoI/2pVatmQRqeeoqN X-Received: by 2002:a17:902:b416:: with SMTP id x22-v6mr3744797plr.267.1527702009629; Wed, 30 May 2018 10:40:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527702009; cv=none; d=google.com; s=arc-20160816; b=PghJMmKIF0mwMoHtoLEYC4P0wWgwIsDJKx98nT0WDVx+pEV06aPYzxyYzxhmT+6A/V 4jeueoNZzAPzZNY0VywmTbdTjYDWJY602DK9SC5VWNUDWTSiczc2Un4joyF5adtMsn6p 6ERC19esDug/2irf9VvWXf18aN3spPBCIf/ecUDxpcZq1yA2qzT3HU9y4lYoGtXmLE2Z rtfZr4g3HzjcLNOiJ53LLXtHsZWdM7Xgy5DHGU4v/qGIwB3w0nZlWpJa/RlOj/tR6B9T 0D3Tpp4Jqi4dPEsOMb9fHKF7ej/E3VFHhXaDommXsrqg6iDR+hi+VcV01qIFB5OrLTPt XOIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=+BUta1/PcK6ihQrzhPchpZaeP6n8WfQh5XhsxYwZfWA=; b=ewtUHnrcSHYPaj5qC47Ly7NZOLdnNXyTrGDEXp7x435G+fkA3SF1Oqy6RgVsRj9mJr 3DnAiPth70tkBOt3ME55afORfIqSDmVnCKzwpe87w43FCRt5v6CBBcSUVy3xj5sTvv4Z zMc9ucCpgC7joC70Uh8Oe6Uh6/ERe4HrqYB2YiKeuvCd4Y+311jQP6zhUrSqtVVNnsVD V+Nu6jq6x0OJrXp0nSwwR4n0KSwz9IbmSVJOoichj6uz0RIUuOduqMdbbwEuXNk/+3nH 6w3P6BM67PedNQrZCcYql9ISMrDD3hI3UYl7dWNtauL59nGDXTCOEj3WFTJ9MIsekiRm Z0pw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=r3GPTwbK; 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=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ay3-v6si34930524plb.361.2018.05.30.10.39.55; Wed, 30 May 2018 10:40:09 -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=@oracle.com header.s=corp-2017-10-26 header.b=r3GPTwbK; 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=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932091AbeE3Rj3 (ORCPT + 99 others); Wed, 30 May 2018 13:39:29 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:33188 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751833AbeE3Rj0 (ORCPT ); Wed, 30 May 2018 13:39:26 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4UHUnHU127886; Wed, 30 May 2018 17:39:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=+BUta1/PcK6ihQrzhPchpZaeP6n8WfQh5XhsxYwZfWA=; b=r3GPTwbKUay3Du6RBcz/LjM/KiAFO1GROSWfwK69kMXdpYqxw3OlLJF2Ke2yHlC8Zy2+ NGtKrvT4dl0WOF7VQnhogslzgcLt5OeDMQAuotYb+XmyghQcVZWzcpdksngeR3RV+W/q U2yAUi0yYY7x50iS2iy+yaMQ+0FG1o2FLvHeOPs/idHwJ1E9iSQ9PY/r4aKFmuph343u dBu0SceubbUW73gU/UIgBF8BqiNL2KPY4f93aA+bZ+VvPoLXPIw7cIklr5wU+H+fBxzG eDM9z3fHlXlnm/ybf0cNfDaOApPacOWPUjT6nqVoYa88JCbJY5ZolKtBdeYvJvLPx09z yA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2j9ev83p8n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 May 2018 17:39:17 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w4UHdG5V020459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 May 2018 17:39:16 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w4UHdDCF027068; Wed, 30 May 2018 17:39:15 GMT Received: from [192.168.1.122] (/24.130.61.68) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 May 2018 10:39:12 -0700 Subject: Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks To: Eric Dumazet , David Miller Cc: 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> From: Qing Huang Message-ID: <05a97a57-2a25-34b5-e8eb-6452d6bb419a@oracle.com> Date: Wed, 30 May 2018 10:39:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8909 signatures=668702 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1805300186 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/29/2018 8:49 PM, 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 > Would this just fail the allocation without trying to reclaim memory under memory pressure? We've tried something similar but it didn't fix the original problem we were facing. >> page = alloc_pages_node(node, gfp_mask, order); >> if (!page) { >> page = alloc_pages(gfp_mask, order); >>