[RFC 0/3] TTM priority queue logic

[RFC 0/3] TTM priority queue logic

[Lauri Kasanen]

Hi list, Thomas,

I'd like to know if this is going in the right direction.

I've implemented a priority queue on top of the kernel rb tree and
linked list. It's been tested well in userspace.

I hardcoded radeon to input the buffer size as the score. Nothing blew
up, games ran fine, and even got ~2% more fps on average*.

The only thing missing from this code is the "if score is too low, and
there is no room without eviction, tell driver so" logic.

- Lauri

* This is a fairly bad strategy, and according to my simulator achieves
16% worse results compared to LRU in heavier situations. The games
tested here all fit in VRAM, which should explain the improvement.

Re: [RFC 0/3] TTM priority queue logic

[Thomas Hellstrom]

On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
> Hi list, Thomas,
>
> I'd like to know if this is going in the right direction.
>
> I've implemented a priority queue on top of the kernel rb tree and
> linked list. It's been tested well in userspace.
>
> I hardcoded radeon to input the buffer size as the score. Nothing blew
> up, games ran fine, and even got ~2% more fps on average*.
>
> The only thing missing from this code is the "if score is too low, and
> there is no room without eviction, tell driver so" logic.
>
> - Lauri
>
> * This is a fairly bad strategy, and according to my simulator achieves
> 16% worse results compared to LRU in heavier situations. The games
> tested here all fit in VRAM, which should explain the improvement

Lauri, I'm out of the office until monday, I'll take a look then.
Thanks,

Thomas

Re: [RFC 0/3] TTM priority queue logic

[Thomas Hellstrom]

Hi, Lauri.

On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
> Hi list, Thomas,
>
> I'd like to know if this is going in the right direction.

This looks fine with me.

However, if possible I'd like the drivers to enable both alloc_threshold
and priority queue on a per-memory-type basis.

That would mean no new arguments (use_pqueue, alloc_threshold) in
ttm_bo_device_init(). Instead, set default values in
ttm_bo_init_mm(), and let the driver change them in the init_mem_type()
callback.

Do you think that would work?

/Thomas

Re: [RFC 0/3] TTM priority queue logic

[Lauri Kasanen]

On Mon, 07 Apr 2014 14:25:28 +0200
Thomas Hellstrom <thellstrom@vmware.com> wrote:

> Hi, Lauri.
> 
> On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
> > Hi list, Thomas,
> >
> > I'd like to know if this is going in the right direction.
> 
> This looks fine with me.
> 
> However, if possible I'd like the drivers to enable both alloc_threshold
> and priority queue on a per-memory-type basis.
> 
> That would mean no new arguments (use_pqueue, alloc_threshold) in
> ttm_bo_device_init(). Instead, set default values in
> ttm_bo_init_mm(), and let the driver change them in the init_mem_type()
> callback.
> 
> Do you think that would work?

Thanks for the review.

Alloc_threshold was removed, and the current patch (in drm-next)
replaced it with a placement flag. So now that logic is in the driver.

Making the pqueue a per-type option would certainly work, I'll edit it
to do so. I don't see why it would improve GTT or SYSTEM given their
perf characteristics, but I suppose future devices can always do weird
things.

- Lauri

Re: [RFC 0/3] TTM priority queue logic

[Thomas Hellstrom]

On 04/07/2014 04:39 PM, Lauri Kasanen wrote:
> On Mon, 07 Apr 2014 14:25:28 +0200
> Thomas Hellstrom <thellstrom@vmware.com> wrote:
>
>> Hi, Lauri.
>>
>> On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
>>> Hi list, Thomas,
>>>
>>> I'd like to know if this is going in the right direction.
>> This looks fine with me.
>>
>> However, if possible I'd like the drivers to enable both alloc_threshold
>> and priority queue on a per-memory-type basis.
>>
>> That would mean no new arguments (use_pqueue, alloc_threshold) in
>> ttm_bo_device_init(). Instead, set default values in
>> ttm_bo_init_mm(), and let the driver change them in the init_mem_type()
>> callback.
>>
>> Do you think that would work?
> Thanks for the review.
>
> Alloc_threshold was removed, and the current patch (in drm-next)
> replaced it with a placement flag. So now that logic is in the driver.
>
> Making the pqueue a per-type option would certainly work, I'll edit it
> to do so. I don't see why it would improve GTT or SYSTEM given their
> perf characteristics, but I suppose future devices can always do weird
> things.

Yes. You don't have to explicitly check for VRAM, and drivers can also
set up
other fixed memory types, like a pre-allocated chunk of GTT.

Thanks,
Thomas


> - Lauri