AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
	amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: kernel-dev@igalia.com,
	Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Subject: Re: [RFC v2 4/5] drm/ttm: Allow drivers to specify maximum beneficial TTM pool size
Date: Tue, 7 Oct 2025 17:36:19 +0200	[thread overview]
Message-ID: <4f2e1bef-28c1-4af2-b088-ca4f907fa152@amd.com> (raw)
In-Reply-To: <cfb8ec02-4870-469a-9d23-51e3c0f1778c@igalia.com>

On 07.10.25 15:57, Tvrtko Ursulin wrote:
>>>   -#define TTM_POOL_USE_DMA_ALLOC     BIT(0) /* Use coherent DMA allocations. */
>>> -#define TTM_POOL_USE_DMA32    BIT(1) /* Use GFP_DMA32 allocations. */
>>> +#define TTM_POOL_BENEFICIAL_ORDER(n)    ((n) & 0xff) /* Max order which caller can benefit from */
>>
>> Looks good in general, but I'm not 100% convinced that we want to mix this value into the flags.
>>
>> On the one hand it makes your live easier because you don't need to change all drivers using it, on the other hand changing all drivers using it would potentially be cleaner and document the value better.
> 
> I was not 100% convinced either but it looked a reasonable compromise.
> 
> My thinking was to not simply add an int after the existing two booleans but to try and clean it up at the same time. Once I replaced them with flags then the option were to either add a new int argument or add some flags like TTM_POOL_BENEFICIAL_SIZE_2M, TTM_POOL_BENEFICIAL_SIZE_64K, with the thinking there probably isn't a full range of page sizes. But then I thought why not just put the order in some bits. Advantages being it adds names to anonymous booleans and is extensible with no further churn.
> 
> But I don't know, I am happy to change it to something else if you are sure this isn't the way.
> 
> If we add a new int then it has to have some "stick with default" semantics. Like -1 or whatnot. With is also meh. I wouldn't do a zero because it feels conflated.

Ideally drivers would use MAX_PAGE_ORDER, but yeah that is quite some work to do.

Feel free to go ahead with the flags approach, it should solve the problem and is not much work for now.

Regards,
Christian.

> 
> Regards,
> 
> Tvrtko
> 
>>> +#define TTM_POOL_USE_DMA_ALLOC         BIT(8) /* Use coherent DMA allocations. */
>>> +#define TTM_POOL_USE_DMA32        BIT(9) /* Use GFP_DMA32 allocations. */
>>>     /**
>>>    * struct ttm_pool - Pool for all caching and orders
>>> @@ -111,4 +112,9 @@ static inline bool ttm_pool_uses_dma32(struct ttm_pool *pool)
>>>       return pool->flags & TTM_POOL_USE_DMA32;
>>>   }
>>>   +static inline bool ttm_pool_beneficial_order(struct ttm_pool *pool)
>>> +{
>>> +    return pool->flags & 0xff;
>>> +}
>>> +
>>>   #endif
>>
> 


  reply	other threads:[~2025-10-07 15:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-03 13:58 [RFC v2 0/5] Improving the worst case TTM large allocation latency Tvrtko Ursulin
2025-10-03 13:58 ` [RFC v2 1/5] drm/ttm: Add getter for some pool properties Tvrtko Ursulin
2025-10-06  8:38   ` Christian König
2025-10-07 14:00     ` Tvrtko Ursulin
2025-10-07 14:03       ` Christian König
2025-10-07 14:27         ` Tvrtko Ursulin
2025-10-07 15:04           ` Christian König
2025-10-08  7:34             ` Tvrtko Ursulin
2025-10-08 10:01               ` Christian König
2025-10-03 13:58 ` [RFC v2 2/5] drm/ttm: Replace multiple booleans with flags in pool init Tvrtko Ursulin
2025-10-03 13:58 ` [RFC v2 3/5] drm/ttm: Replace multiple booleans with flags in device init Tvrtko Ursulin
2025-10-03 13:58 ` [RFC v2 4/5] drm/ttm: Allow drivers to specify maximum beneficial TTM pool size Tvrtko Ursulin
2025-10-06  9:49   ` Christian König
2025-10-07 13:57     ` Tvrtko Ursulin
2025-10-07 15:36       ` Christian König [this message]
2025-10-03 13:58 ` [RFC v2 5/5] drm/amdgpu: Configure max beneficial TTM pool allocation order Tvrtko Ursulin

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=4f2e1bef-28c1-4af2-b088-ca4f907fa152@amd.com \
    --to=christian.koenig@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=cascardo@igalia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel-dev@igalia.com \
    --cc=tvrtko.ursulin@igalia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox