Received: by 10.192.165.148 with SMTP id m20csp2502414imm; Sun, 29 Apr 2018 00:06:42 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpX6LrbpdasMhIaR6dBdjjzPXW3TBsfzXEVUXY1GOOWzosB0LP087kgn1QHgTXih1ChK+SD X-Received: by 10.98.233.3 with SMTP id j3mr5188356pfh.196.1524985602813; Sun, 29 Apr 2018 00:06:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524985602; cv=none; d=google.com; s=arc-20160816; b=Z0owgsO2u3aB0M3CK6txxHrzIbSX7eTkmLlxXYub9vjfs9t8fvdj40yCvPbslbVXNm ZZ+4qrjV1EJ73zefAWeRuF2Og+x64UfOdcVrv7Cfl3P5vydm75Tn7eDNA2eJgboCayXs UbxiEyAHWPQJYUaghCpZjXXgWNOChayzzNpc66w9dSCufCJeUuFhZcz9AxsOAx+DWgiu n5pM6f+6lzqQRgSV07yUlV0rvGvvwJuBZ9aQZncepcqdidlxXxHp172j+6Zin4rGtgDx DQGNhG1svCGtKiSStSxoxJf33R2BGxza8F7iDqBI1oV7AXvGrG9/OCXhl7Gcdc6FRUNs C+wQ== 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:reply-to:dkim-signature :arc-authentication-results; bh=DQDELUqKtvIhC9enG1MSWhaz7r/uyrZsUG4AX44MJ/o=; b=NTowbBlomlKJK4275uQLSFi0KegPVxJJcDQoJVgi4S4oqhpj4T13hmsad1WZfWH5uF nRd2PM/YlFwJIbTxrUXRj8qNjbk8StWRHFBlFU6QPTU9NQXXGScsLAhWgcFLnJLLggeS /vg5WZwOCg2FWthWLkmq8d7mrO7WsJ6R/fQOX7fKQKPVNGmp22wdc0p+0qVflxPz+/Ka MdQ6KQl5k71bLyev91jSApzNDbzHiAJOHQE5KvnSfOa+x9rtOe6JJypFy2kcUgnx4WIo XhnjZXacddXWbUdIUxh3pqsLnsPCEDy529AztzzEmuTkM3JojrZPnjnHVoifHw7xSazS 22Rw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=rKJiwUGj; 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 l5-v6si5035923pls.144.2018.04.29.00.06.28; Sun, 29 Apr 2018 00:06:42 -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=rKJiwUGj; 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 S1752889AbeD2HFA (ORCPT + 99 others); Sun, 29 Apr 2018 03:05:00 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:51259 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752767AbeD2HE7 (ORCPT ); Sun, 29 Apr 2018 03:04:59 -0400 Received: by mail-wm0-f68.google.com with SMTP id j4so8407719wme.1 for ; Sun, 29 Apr 2018 00:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=DQDELUqKtvIhC9enG1MSWhaz7r/uyrZsUG4AX44MJ/o=; b=rKJiwUGjpzEBKNjA4e9faIDYBKxpWFP1JtJiYP9o4uw+23HJr+twjr/nh0MNJU90O/ wY6czHg4UeFThjH9epCskYI+DLksB8y0XXiP1OMoOMsBq4GNn5meuDxbHrrzfE5b0xIq y1ZK2wllNxB90cYi6AmdnU/BNe+EIxrgKTlUMfEO/vRJDFsZKafcpobmrAl6Hnw3HIEy z+o8bCjt3k6cbVWYhPHLkekys9eM8Se5jIVlsXQYwhEtj40E2rhOG348W4yypXTcFMlE TzroJY6vWmMLBEjktyrQnNfZoUHnHkck1Tizb6Rk5PQtSmS9nv+XtYN7l1RHmxVQ3SKo fXGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=DQDELUqKtvIhC9enG1MSWhaz7r/uyrZsUG4AX44MJ/o=; b=YSGeuODaFWdhJC2Een32LPfryAzlemw5s8IolbYltF2sq0PlDBMrE1ZvQjO9RonU8s qIXScsHVQR1x1ZVlwRhwkZqPdDmrMPBSWYgg3mFmwA/sZwJZSgm15vnUFHQd1kAoLX60 uw1s/hQb1bLFLoPjs06C0Ts+nNGt/qTKlJH7gVcvNsTqsesfekas52DrtiCRt0y/uvxn sAZI52jysajrcLhQeRS8R6LjjD2K10LwmMaFEz8tSNBO/ePMIZ1Ny4tt2EKBkXdJWw4K tBC1uCR4+Iv/UPSRfvOinEkhjqn2Y4UMwh0/s0l+xaT2Dw+iAaCZh94NXKyVNUfL2Cn2 xvUw== X-Gm-Message-State: ALQs6tC4kH7V4bKznqUaN7p9tr2BRXccz6h1jzZ2Xp3J469vFYr9VTNc +JY/5PQvZM0cD+3FsmyBIHyOZiSL X-Received: by 10.28.224.6 with SMTP id x6mr4527531wmg.80.1524985497449; Sun, 29 Apr 2018 00:04:57 -0700 (PDT) Received: from ?IPv6:2a02:908:1257:4460:1ab8:55c1:a639:6740? ([2a02:908:1257:4460:1ab8:55c1:a639:6740]) by smtp.gmail.com with ESMTPSA id m16sm6999114wmb.42.2018.04.29.00.04.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Apr 2018 00:04:56 -0700 (PDT) Reply-To: christian.koenig@amd.com Subject: Re: [PATCH 2/2] drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages To: =?UTF-8?Q?Michel_D=c3=a4nzer?= , =?UTF-8?Q?Christian_K=c3=b6nig?= , Roger He Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20180426150618.13470-1-michel@daenzer.net> <20180426150618.13470-2-michel@daenzer.net> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <9ae5f860-e893-40ed-febd-986bda5ba3ef@gmail.com> Date: Sun, 29 Apr 2018 09:04:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180426150618.13470-2-michel@daenzer.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 26.04.2018 um 17:06 schrieb Michel Dänzer: > From: Michel Dänzer > > GFP_TRANSHUGE tries very hard to allocate huge pages, which can result > in long delays with high memory pressure. I have observed firefox > freezing for up to around a minute due to this while restic was taking > a full system backup. > > Since we don't really need huge pages, use GFP_TRANSHUGE_LIGHT | > __GFP_NORETRY instead, in order to fail quickly when there are no huge > pages available. Yeah, that goes into the direction Felix already suggested as well. > Set __GFP_KSWAPD_RECLAIM as well, in order for huge pages to be freed > up in the background if necessary. And that is even better, thanks. > > With these changes, I'm no longer seeing freezes during a restic backup. > > Cc: stable@vger.kernel.org > Signed-off-by: Michel Dänzer Reviewed-by: Christian König Regards, Christian. > --- > drivers/gpu/drm/ttm/ttm_page_alloc.c | 11 ++++++++--- > drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 3 ++- > 2 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c > index 2ce91272b111..6794f15461d9 100644 > --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c > +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c > @@ -914,7 +914,8 @@ static int ttm_get_pages(struct page **pages, unsigned npages, int flags, > while (npages >= HPAGE_PMD_NR) { > gfp_t huge_flags = gfp_flags; > > - huge_flags |= GFP_TRANSHUGE; > + huge_flags |= GFP_TRANSHUGE_LIGHT | __GFP_NORETRY | > + __GFP_KSWAPD_RECLAIM; > huge_flags &= ~__GFP_MOVABLE; > huge_flags &= ~__GFP_COMP; > p = alloc_pages(huge_flags, HPAGE_PMD_ORDER); > @@ -1033,11 +1034,15 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages) > GFP_USER | GFP_DMA32, "uc dma", 0); > > ttm_page_pool_init_locked(&_manager->wc_pool_huge, > - GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP), > + (GFP_TRANSHUGE_LIGHT | __GFP_NORETRY | > + __GFP_KSWAPD_RECLAIM) & > + ~(__GFP_MOVABLE | __GFP_COMP), > "wc huge", order); > > ttm_page_pool_init_locked(&_manager->uc_pool_huge, > - GFP_TRANSHUGE & ~(__GFP_MOVABLE | __GFP_COMP) > + (GFP_TRANSHUGE_LIGHT | __GFP_NORETRY | > + __GFP_KSWAPD_RECLAIM) & > + ~(__GFP_MOVABLE | __GFP_COMP) > , "uc huge", order); > > _manager->options.max_size = max_pages; > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > index 291b04213ec5..5a551158c289 100644 > --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > @@ -910,7 +910,8 @@ static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt *ttm_dma, bool huge) > gfp_flags |= __GFP_ZERO; > > if (huge) { > - gfp_flags |= GFP_TRANSHUGE; > + gfp_flags |= GFP_TRANSHUGE_LIGHT | __GFP_NORETRY | > + __GFP_KSWAPD_RECLAIM; > gfp_flags &= ~__GFP_MOVABLE; > gfp_flags &= ~__GFP_COMP; > }