All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	"Matthew Auld" <matthew.auld@intel.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	intel-xe@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
Date: Tue, 11 Apr 2023 15:45:42 +0200	[thread overview]
Message-ID: <ZDVkhtx1/uToLM5R@phenom.ffwll.local> (raw)
In-Reply-To: <33b145f1-fce5-95f1-357d-dda128e3548d@amd.com>

On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote:
> Am 11.04.23 um 11:51 schrieb Daniel Vetter:
> > On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote:
> > > When swapping out, we will split multi-order pages both in order to
> > > move them to the swap-cache and to be able to return memory to the
> > > swap cache as soon as possible on a page-by-page basis.
> > > Reduce the page max order to the system PMD size, as we can then be nicer
> > > to the system and avoid splitting gigantic pages.
> > > 
> > > Looking forward to when we might be able to swap out PMD size folios
> > > without splitting, this will also be a benefit.
> > > 
> > > v2:
> > > - Include all orders up to the PMD size (Christian König)
> > > v3:
> > > - Avoid compilation errors for architectures with special PFN_SHIFTs
> > > 
> > > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Apparently this fails on ppc build testing. Please supply build fix asap
> > (or I guess we need to revert). I'm kinda not clear why this only showed
> > up when I merged the drm-misc-next pr into drm-next ...
> 
> I'm really wondering this as well. It looks like PMD_SHIFT isn't a constant
> on this particular platform.
> 
> But from what I can find in the upstream 6.2 kernel PMD_SHIFT always seems
> to be a constant.
> 
> So how exactly can that here break?

There's some in-flight patches to rework MAX_ORDER and other things in
linux-next, maybe it's recent? If you check out linux-next then you need
to reapply the patch (since sfr reverted it).
-Daniel

> 
> Christian.
> 
> > -Daniel
> > 
> > > ---
> > >   drivers/gpu/drm/ttm/ttm_pool.c | 30 +++++++++++++++++++-----------
> > >   1 file changed, 19 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> > > index dfce896c4bae..18c342a919a2 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > > @@ -47,6 +47,11 @@
> > >   #include "ttm_module.h"
> > > +#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
> > > +#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
> > > +/* Some architectures have a weird PMD_SHIFT */
> > > +#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? __TTM_DIM_ORDER : MAX_ORDER)
> > > +
> > >   /**
> > >    * struct ttm_pool_dma - Helper object for coherent DMA mappings
> > >    *
> > > @@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644);
> > >   static atomic_long_t allocated_pages;
> > > -static struct ttm_pool_type global_write_combined[MAX_ORDER];
> > > -static struct ttm_pool_type global_uncached[MAX_ORDER];
> > > +static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
> > > +static struct ttm_pool_type global_uncached[TTM_DIM_ORDER];
> > > -static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
> > > -static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
> > > +static struct ttm_pool_type global_dma32_write_combined[TTM_DIM_ORDER];
> > > +static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER];
> > >   static spinlock_t shrinker_lock;
> > >   static struct list_head shrinker_list;
> > > @@ -444,7 +449,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
> > >   	else
> > >   		gfp_flags |= GFP_HIGHUSER;
> > > -	for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
> > > +	for (order = min_t(unsigned int, TTM_MAX_ORDER, __fls(num_pages));
> > >   	     num_pages;
> > >   	     order = min_t(unsigned int, order, __fls(num_pages))) {
> > >   		struct ttm_pool_type *pt;
> > > @@ -563,7 +568,7 @@ void ttm_pool_init(struct ttm_pool *pool, struct device *dev,
> > >   	if (use_dma_alloc) {
> > >   		for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > -			for (j = 0; j < MAX_ORDER; ++j)
> > > +			for (j = 0; j < TTM_DIM_ORDER; ++j)
> > >   				ttm_pool_type_init(&pool->caching[i].orders[j],
> > >   						   pool, i, j);
> > >   	}
> > > @@ -583,7 +588,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
> > >   	if (pool->use_dma_alloc) {
> > >   		for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > -			for (j = 0; j < MAX_ORDER; ++j)
> > > +			for (j = 0; j < TTM_DIM_ORDER; ++j)
> > >   				ttm_pool_type_fini(&pool->caching[i].orders[j]);
> > >   	}
> > > @@ -637,7 +642,7 @@ static void ttm_pool_debugfs_header(struct seq_file *m)
> > >   	unsigned int i;
> > >   	seq_puts(m, "\t ");
> > > -	for (i = 0; i < MAX_ORDER; ++i)
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i)
> > >   		seq_printf(m, " ---%2u---", i);
> > >   	seq_puts(m, "\n");
> > >   }
> > > @@ -648,7 +653,7 @@ static void ttm_pool_debugfs_orders(struct ttm_pool_type *pt,
> > >   {
> > >   	unsigned int i;
> > > -	for (i = 0; i < MAX_ORDER; ++i)
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i)
> > >   		seq_printf(m, " %8u", ttm_pool_type_count(&pt[i]));
> > >   	seq_puts(m, "\n");
> > >   }
> > > @@ -751,13 +756,16 @@ int ttm_pool_mgr_init(unsigned long num_pages)
> > >   {
> > >   	unsigned int i;
> > > +	BUILD_BUG_ON(TTM_DIM_ORDER > MAX_ORDER);
> > > +	BUILD_BUG_ON(TTM_DIM_ORDER < 1);
> > > +
> > >   	if (!page_pool_size)
> > >   		page_pool_size = num_pages;
> > >   	spin_lock_init(&shrinker_lock);
> > >   	INIT_LIST_HEAD(&shrinker_list);
> > > -	for (i = 0; i < MAX_ORDER; ++i) {
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i) {
> > >   		ttm_pool_type_init(&global_write_combined[i], NULL,
> > >   				   ttm_write_combined, i);
> > >   		ttm_pool_type_init(&global_uncached[i], NULL, ttm_uncached, i);
> > > @@ -790,7 +798,7 @@ void ttm_pool_mgr_fini(void)
> > >   {
> > >   	unsigned int i;
> > > -	for (i = 0; i < MAX_ORDER; ++i) {
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i) {
> > >   		ttm_pool_type_fini(&global_write_combined[i]);
> > >   		ttm_pool_type_fini(&global_uncached[i]);
> > > -- 
> > > 2.39.2
> > > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <christian.koenig@amd.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Matthew Auld <matthew.auld@intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
Date: Tue, 11 Apr 2023 15:45:42 +0200	[thread overview]
Message-ID: <ZDVkhtx1/uToLM5R@phenom.ffwll.local> (raw)
In-Reply-To: <33b145f1-fce5-95f1-357d-dda128e3548d@amd.com>

On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote:
> Am 11.04.23 um 11:51 schrieb Daniel Vetter:
> > On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote:
> > > When swapping out, we will split multi-order pages both in order to
> > > move them to the swap-cache and to be able to return memory to the
> > > swap cache as soon as possible on a page-by-page basis.
> > > Reduce the page max order to the system PMD size, as we can then be nicer
> > > to the system and avoid splitting gigantic pages.
> > > 
> > > Looking forward to when we might be able to swap out PMD size folios
> > > without splitting, this will also be a benefit.
> > > 
> > > v2:
> > > - Include all orders up to the PMD size (Christian König)
> > > v3:
> > > - Avoid compilation errors for architectures with special PFN_SHIFTs
> > > 
> > > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Apparently this fails on ppc build testing. Please supply build fix asap
> > (or I guess we need to revert). I'm kinda not clear why this only showed
> > up when I merged the drm-misc-next pr into drm-next ...
> 
> I'm really wondering this as well. It looks like PMD_SHIFT isn't a constant
> on this particular platform.
> 
> But from what I can find in the upstream 6.2 kernel PMD_SHIFT always seems
> to be a constant.
> 
> So how exactly can that here break?

There's some in-flight patches to rework MAX_ORDER and other things in
linux-next, maybe it's recent? If you check out linux-next then you need
to reapply the patch (since sfr reverted it).
-Daniel

> 
> Christian.
> 
> > -Daniel
> > 
> > > ---
> > >   drivers/gpu/drm/ttm/ttm_pool.c | 30 +++++++++++++++++++-----------
> > >   1 file changed, 19 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> > > index dfce896c4bae..18c342a919a2 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > > @@ -47,6 +47,11 @@
> > >   #include "ttm_module.h"
> > > +#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
> > > +#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
> > > +/* Some architectures have a weird PMD_SHIFT */
> > > +#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? __TTM_DIM_ORDER : MAX_ORDER)
> > > +
> > >   /**
> > >    * struct ttm_pool_dma - Helper object for coherent DMA mappings
> > >    *
> > > @@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644);
> > >   static atomic_long_t allocated_pages;
> > > -static struct ttm_pool_type global_write_combined[MAX_ORDER];
> > > -static struct ttm_pool_type global_uncached[MAX_ORDER];
> > > +static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
> > > +static struct ttm_pool_type global_uncached[TTM_DIM_ORDER];
> > > -static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
> > > -static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
> > > +static struct ttm_pool_type global_dma32_write_combined[TTM_DIM_ORDER];
> > > +static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER];
> > >   static spinlock_t shrinker_lock;
> > >   static struct list_head shrinker_list;
> > > @@ -444,7 +449,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
> > >   	else
> > >   		gfp_flags |= GFP_HIGHUSER;
> > > -	for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
> > > +	for (order = min_t(unsigned int, TTM_MAX_ORDER, __fls(num_pages));
> > >   	     num_pages;
> > >   	     order = min_t(unsigned int, order, __fls(num_pages))) {
> > >   		struct ttm_pool_type *pt;
> > > @@ -563,7 +568,7 @@ void ttm_pool_init(struct ttm_pool *pool, struct device *dev,
> > >   	if (use_dma_alloc) {
> > >   		for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > -			for (j = 0; j < MAX_ORDER; ++j)
> > > +			for (j = 0; j < TTM_DIM_ORDER; ++j)
> > >   				ttm_pool_type_init(&pool->caching[i].orders[j],
> > >   						   pool, i, j);
> > >   	}
> > > @@ -583,7 +588,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
> > >   	if (pool->use_dma_alloc) {
> > >   		for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > -			for (j = 0; j < MAX_ORDER; ++j)
> > > +			for (j = 0; j < TTM_DIM_ORDER; ++j)
> > >   				ttm_pool_type_fini(&pool->caching[i].orders[j]);
> > >   	}
> > > @@ -637,7 +642,7 @@ static void ttm_pool_debugfs_header(struct seq_file *m)
> > >   	unsigned int i;
> > >   	seq_puts(m, "\t ");
> > > -	for (i = 0; i < MAX_ORDER; ++i)
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i)
> > >   		seq_printf(m, " ---%2u---", i);
> > >   	seq_puts(m, "\n");
> > >   }
> > > @@ -648,7 +653,7 @@ static void ttm_pool_debugfs_orders(struct ttm_pool_type *pt,
> > >   {
> > >   	unsigned int i;
> > > -	for (i = 0; i < MAX_ORDER; ++i)
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i)
> > >   		seq_printf(m, " %8u", ttm_pool_type_count(&pt[i]));
> > >   	seq_puts(m, "\n");
> > >   }
> > > @@ -751,13 +756,16 @@ int ttm_pool_mgr_init(unsigned long num_pages)
> > >   {
> > >   	unsigned int i;
> > > +	BUILD_BUG_ON(TTM_DIM_ORDER > MAX_ORDER);
> > > +	BUILD_BUG_ON(TTM_DIM_ORDER < 1);
> > > +
> > >   	if (!page_pool_size)
> > >   		page_pool_size = num_pages;
> > >   	spin_lock_init(&shrinker_lock);
> > >   	INIT_LIST_HEAD(&shrinker_list);
> > > -	for (i = 0; i < MAX_ORDER; ++i) {
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i) {
> > >   		ttm_pool_type_init(&global_write_combined[i], NULL,
> > >   				   ttm_write_combined, i);
> > >   		ttm_pool_type_init(&global_uncached[i], NULL, ttm_uncached, i);
> > > @@ -790,7 +798,7 @@ void ttm_pool_mgr_fini(void)
> > >   {
> > >   	unsigned int i;
> > > -	for (i = 0; i < MAX_ORDER; ++i) {
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i) {
> > >   		ttm_pool_type_fini(&global_write_combined[i]);
> > >   		ttm_pool_type_fini(&global_uncached[i]);
> > > -- 
> > > 2.39.2
> > > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	"Matthew Auld" <matthew.auld@intel.com>,
	intel-xe@lists.freedesktop.org
Subject: Re: [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
Date: Tue, 11 Apr 2023 15:45:42 +0200	[thread overview]
Message-ID: <ZDVkhtx1/uToLM5R@phenom.ffwll.local> (raw)
In-Reply-To: <33b145f1-fce5-95f1-357d-dda128e3548d@amd.com>

On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote:
> Am 11.04.23 um 11:51 schrieb Daniel Vetter:
> > On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote:
> > > When swapping out, we will split multi-order pages both in order to
> > > move them to the swap-cache and to be able to return memory to the
> > > swap cache as soon as possible on a page-by-page basis.
> > > Reduce the page max order to the system PMD size, as we can then be nicer
> > > to the system and avoid splitting gigantic pages.
> > > 
> > > Looking forward to when we might be able to swap out PMD size folios
> > > without splitting, this will also be a benefit.
> > > 
> > > v2:
> > > - Include all orders up to the PMD size (Christian König)
> > > v3:
> > > - Avoid compilation errors for architectures with special PFN_SHIFTs
> > > 
> > > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > > Reviewed-by: Christian König <christian.koenig@amd.com>
> > Apparently this fails on ppc build testing. Please supply build fix asap
> > (or I guess we need to revert). I'm kinda not clear why this only showed
> > up when I merged the drm-misc-next pr into drm-next ...
> 
> I'm really wondering this as well. It looks like PMD_SHIFT isn't a constant
> on this particular platform.
> 
> But from what I can find in the upstream 6.2 kernel PMD_SHIFT always seems
> to be a constant.
> 
> So how exactly can that here break?

There's some in-flight patches to rework MAX_ORDER and other things in
linux-next, maybe it's recent? If you check out linux-next then you need
to reapply the patch (since sfr reverted it).
-Daniel

> 
> Christian.
> 
> > -Daniel
> > 
> > > ---
> > >   drivers/gpu/drm/ttm/ttm_pool.c | 30 +++++++++++++++++++-----------
> > >   1 file changed, 19 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> > > index dfce896c4bae..18c342a919a2 100644
> > > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > > @@ -47,6 +47,11 @@
> > >   #include "ttm_module.h"
> > > +#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
> > > +#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
> > > +/* Some architectures have a weird PMD_SHIFT */
> > > +#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? __TTM_DIM_ORDER : MAX_ORDER)
> > > +
> > >   /**
> > >    * struct ttm_pool_dma - Helper object for coherent DMA mappings
> > >    *
> > > @@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644);
> > >   static atomic_long_t allocated_pages;
> > > -static struct ttm_pool_type global_write_combined[MAX_ORDER];
> > > -static struct ttm_pool_type global_uncached[MAX_ORDER];
> > > +static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
> > > +static struct ttm_pool_type global_uncached[TTM_DIM_ORDER];
> > > -static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
> > > -static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
> > > +static struct ttm_pool_type global_dma32_write_combined[TTM_DIM_ORDER];
> > > +static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER];
> > >   static spinlock_t shrinker_lock;
> > >   static struct list_head shrinker_list;
> > > @@ -444,7 +449,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
> > >   	else
> > >   		gfp_flags |= GFP_HIGHUSER;
> > > -	for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
> > > +	for (order = min_t(unsigned int, TTM_MAX_ORDER, __fls(num_pages));
> > >   	     num_pages;
> > >   	     order = min_t(unsigned int, order, __fls(num_pages))) {
> > >   		struct ttm_pool_type *pt;
> > > @@ -563,7 +568,7 @@ void ttm_pool_init(struct ttm_pool *pool, struct device *dev,
> > >   	if (use_dma_alloc) {
> > >   		for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > -			for (j = 0; j < MAX_ORDER; ++j)
> > > +			for (j = 0; j < TTM_DIM_ORDER; ++j)
> > >   				ttm_pool_type_init(&pool->caching[i].orders[j],
> > >   						   pool, i, j);
> > >   	}
> > > @@ -583,7 +588,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
> > >   	if (pool->use_dma_alloc) {
> > >   		for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > > -			for (j = 0; j < MAX_ORDER; ++j)
> > > +			for (j = 0; j < TTM_DIM_ORDER; ++j)
> > >   				ttm_pool_type_fini(&pool->caching[i].orders[j]);
> > >   	}
> > > @@ -637,7 +642,7 @@ static void ttm_pool_debugfs_header(struct seq_file *m)
> > >   	unsigned int i;
> > >   	seq_puts(m, "\t ");
> > > -	for (i = 0; i < MAX_ORDER; ++i)
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i)
> > >   		seq_printf(m, " ---%2u---", i);
> > >   	seq_puts(m, "\n");
> > >   }
> > > @@ -648,7 +653,7 @@ static void ttm_pool_debugfs_orders(struct ttm_pool_type *pt,
> > >   {
> > >   	unsigned int i;
> > > -	for (i = 0; i < MAX_ORDER; ++i)
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i)
> > >   		seq_printf(m, " %8u", ttm_pool_type_count(&pt[i]));
> > >   	seq_puts(m, "\n");
> > >   }
> > > @@ -751,13 +756,16 @@ int ttm_pool_mgr_init(unsigned long num_pages)
> > >   {
> > >   	unsigned int i;
> > > +	BUILD_BUG_ON(TTM_DIM_ORDER > MAX_ORDER);
> > > +	BUILD_BUG_ON(TTM_DIM_ORDER < 1);
> > > +
> > >   	if (!page_pool_size)
> > >   		page_pool_size = num_pages;
> > >   	spin_lock_init(&shrinker_lock);
> > >   	INIT_LIST_HEAD(&shrinker_list);
> > > -	for (i = 0; i < MAX_ORDER; ++i) {
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i) {
> > >   		ttm_pool_type_init(&global_write_combined[i], NULL,
> > >   				   ttm_write_combined, i);
> > >   		ttm_pool_type_init(&global_uncached[i], NULL, ttm_uncached, i);
> > > @@ -790,7 +798,7 @@ void ttm_pool_mgr_fini(void)
> > >   {
> > >   	unsigned int i;
> > > -	for (i = 0; i < MAX_ORDER; ++i) {
> > > +	for (i = 0; i < TTM_DIM_ORDER; ++i) {
> > >   		ttm_pool_type_fini(&global_write_combined[i]);
> > >   		ttm_pool_type_fini(&global_uncached[i]);
> > > -- 
> > > 2.39.2
> > > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2023-04-11 13:45 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-04 20:06 [Intel-gfx] [PATCH RESEND v3 0/3] drm/ttm: Small fixes / cleanups in prep for shrinking Thomas Hellström
2023-04-04 20:06 ` Thomas Hellström
2023-04-04 20:06 ` [Intel-xe] " Thomas Hellström
2023-04-04 20:06 ` [Intel-gfx] [PATCH RESEND v3 1/3] drm/ttm/pool: Fix ttm_pool_alloc error path Thomas Hellström
2023-04-04 20:06   ` Thomas Hellström
2023-04-04 20:06   ` [Intel-xe] " Thomas Hellström
2023-04-04 20:06 ` [Intel-gfx] [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages Thomas Hellström
2023-04-04 20:06   ` Thomas Hellström
2023-04-04 20:06   ` [Intel-xe] " Thomas Hellström
2023-04-11  9:51   ` [Intel-gfx] " Daniel Vetter
2023-04-11  9:51     ` Daniel Vetter
2023-04-11  9:51     ` [Intel-xe] " Daniel Vetter
2023-04-11 12:11     ` [Intel-gfx] " Christian König
2023-04-11 12:11       ` Christian König
2023-04-11 12:11       ` [Intel-xe] " Christian König
2023-04-11 13:45       ` Daniel Vetter [this message]
2023-04-11 13:45         ` Daniel Vetter
2023-04-11 13:45         ` [Intel-xe] " Daniel Vetter
2023-04-12  9:08         ` [Intel-gfx] " Daniel Vetter
2023-04-12  9:08           ` Daniel Vetter
2023-04-12  9:08           ` [Intel-xe] " Daniel Vetter
2023-04-12 14:17           ` [Intel-gfx] " Christian König
2023-04-12 14:17             ` Christian König
2023-04-12 14:17             ` [Intel-xe] " Christian König
2023-04-13  8:48             ` [Intel-gfx] " Daniel Vetter
2023-04-13  8:48               ` Daniel Vetter
2023-04-13  8:48               ` [Intel-xe] " Daniel Vetter
2023-04-13  9:45               ` [Intel-gfx] " Christian König
2023-04-13  9:45                 ` Christian König
2023-04-13  9:45                 ` [Intel-xe] " Christian König
2023-04-13 13:13                 ` [Intel-gfx] " Daniel Vetter
2023-04-13 13:13                   ` Daniel Vetter
2023-04-13 13:13                   ` [Intel-xe] " Daniel Vetter
2023-04-14 10:11                   ` [Intel-gfx] " Christian König
2023-04-14 10:11                     ` Christian König
2023-04-14 10:11                     ` [Intel-xe] " Christian König
2023-04-17  8:02                     ` [Intel-gfx] " Thomas Hellström
2023-04-17  8:02                       ` Thomas Hellström
2023-04-17  8:02                       ` [Intel-xe] " Thomas Hellström
2023-04-04 20:06 ` [Intel-gfx] [PATCH RESEND v3 3/3] drm/ttm: Make the call to ttm_tt_populate() interruptible when faulting Thomas Hellström
2023-04-04 20:06   ` Thomas Hellström
2023-04-04 20:06   ` [Intel-xe] " Thomas Hellström
2023-04-04 20:09 ` [Intel-xe] ✓ CI.Patch_applied: success for drm/ttm: Small fixes / cleanups in prep for shrinking Patchwork
2023-04-04 20:10 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-04-04 20:14 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-04-04 20:34 ` [Intel-xe] ○ CI.BAT: info " Patchwork
2023-04-04 23:13 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/ttm: Small fixes / cleanups in prep for shrinking (rev3) Patchwork
2023-04-04 23:13 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-04-04 23:23 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-05  9:24 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-04-05 12:32 ` [Intel-gfx] [PATCH RESEND v3 0/3] drm/ttm: Small fixes / cleanups in prep for shrinking Christian König
2023-04-05 12:32   ` Christian König
2023-04-05 12:32   ` [Intel-xe] " Christian König
2023-04-05 12:36   ` [Intel-gfx] " Thomas Hellström
2023-04-05 12:36     ` Thomas Hellström
2023-04-05 12:36     ` [Intel-xe] " Thomas Hellström

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=ZDVkhtx1/uToLM5R@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    /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.