All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>,
	"Christian König" <christian.koenig@amd.com>,
	"Roger He" <Hongbo.He@amd.com>
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages
Date: Sun, 29 Apr 2018 09:04:56 +0200	[thread overview]
Message-ID: <9ae5f860-e893-40ed-febd-986bda5ba3ef@gmail.com> (raw)
In-Reply-To: <20180426150618.13470-2-michel@daenzer.net>

Am 26.04.2018 um 17:06 schrieb Michel Dänzer:
> From: Michel Dänzer <michel.daenzer@amd.com>
>
> 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 <michel.daenzer@amd.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

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;
>   	}

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>,
	"Christian König" <christian.koenig@amd.com>,
	"Roger He" <Hongbo.He@amd.com>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages
Date: Sun, 29 Apr 2018 09:04:56 +0200	[thread overview]
Message-ID: <9ae5f860-e893-40ed-febd-986bda5ba3ef@gmail.com> (raw)
In-Reply-To: <20180426150618.13470-2-michel@daenzer.net>

Am 26.04.2018 um 17:06 schrieb Michel Dänzer:
> From: Michel Dänzer <michel.daenzer@amd.com>
>
> 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 <michel.daenzer@amd.com>

Reviewed-by: Christian König <christian.koenig@amd.com>

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;
>   	}

  reply	other threads:[~2018-04-29  7:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 15:06 [PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE Michel Dänzer
     [not found] ` <20180426150618.13470-1-michel-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-26 15:06   ` [PATCH 2/2] drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages Michel Dänzer
2018-04-26 15:06     ` Michel Dänzer
2018-04-29  7:04     ` Christian König [this message]
2018-04-29  7:04       ` Christian König
2018-04-27  2:51   ` [PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE zhoucm1
2018-04-27  2:51     ` zhoucm1
2018-04-27  8:41     ` Michel Dänzer
2018-04-27  8:41       ` Michel Dänzer
2018-04-27 13:08   ` [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE Michel Dänzer
2018-04-27 13:08     ` Michel Dänzer
     [not found]     ` <20180427130811.7642-1-michel-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-28 16:30       ` Ilia Mirkin
2018-04-28 16:30         ` Ilia Mirkin
     [not found]         ` <CAKb7Uvj6FFRK6dtvR7xpfZDzs0o3QKHq7ESueBBmr_VnQt6XDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-04-28 23:02           ` Michel Dänzer
2018-04-28 23:02             ` Michel Dänzer
2018-04-28 23:56             ` Ilia Mirkin
2018-04-28 23:56               ` Ilia Mirkin
     [not found]               ` <CAKb7UvibaW0d3H++c4dMFgeXQUYTMVFhi1qO=5W-NFbDWVDT2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-05-02  8:08                 ` Michel Dänzer
2018-05-02  8:08                   ` Michel Dänzer
     [not found]             ` <e8166443-14f0-1eb3-a6a2-d425792b0643-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-29  7:02               ` Christian König
2018-04-29  7:02                 ` Christian König
     [not found]                 ` <d5f9459e-801c-e592-d06d-c9052ef3ad4d-5C7GfCeVMHo@public.gmane.org>
2018-04-30 16:33                   ` Michel Dänzer
2018-04-30 16:33                     ` Michel Dänzer
     [not found]                     ` <e5256136-6da0-cc5e-9490-5a70c89dfd83-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-04-30 18:22                       ` Christian König
2018-04-30 18:22                         ` Christian König
     [not found]                         ` <361a765a-f491-4450-867e-fa88857827ee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-04-30 23:15                           ` Dave Airlie
2018-04-30 23:15                             ` Dave Airlie
     [not found]                             ` <CAPM=9tzmmT5G5a_2WCH5xpRr6rhY6sHdi-Kg5my0az_=haVZTw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-05-01 13:59                               ` Michel Dänzer
2018-05-01 13:59                                 ` Michel Dänzer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9ae5f860-e893-40ed-febd-986bda5ba3ef@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=Hongbo.He@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel@daenzer.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.