All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thellstrom@vmware.com>
To: Lauri Kasanen <cand@gmx.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: TTM's role in score-based eviction
Date: Thu, 05 Dec 2013 11:26:46 +0100	[thread overview]
Message-ID: <52A054E6.4060908@vmware.com> (raw)
In-Reply-To: <20131205113658.52c84991.cand@gmx.com>

Hi!

On 12/05/2013 10:36 AM, Lauri Kasanen wrote:
> Hi list, Thomas,
>
> I will be investigating the use of a hotness score for each bo, to
> replace the ping-pong causing LRU eviction in radeon*.
>
> The goal is to put all bos that fit in VRAM there, in order of hotness;
> a new bo should only be placed there if its hotness score is greater
> than the lowest VRAM bo's. Then the lowest-hotness-bos in
> VRAM should be evicted until the new bo fits. This should result in a
> more stable set with less ping-pong.
>
> Jerome advised that the bo placement should be done entirely outside
> TTM. As I'm not (yet) too familiar with that side of the kernel, what is
> the opinion of TTM folks?

There are a couple of things to be considered:
1) You need to decide where a bo to be validated should be placed. The 
driver can give a list of possible placements to TTM and let
TTM decide, trying each placement in turn. A driver that thinks this 
isn't sufficient can come up with its on strategy and give only a single 
placement to TTM. If TTM can't satisfy that, it will give you an error 
back, and the driver will need to validate with an alternative 
placement. I think Radeon already does this? vmwgfx does it to some extent.

2) As you say, TTM is evicting strictly on an lru basis, and is 
maintaining one LRU list per memory type, and also a global swap lru 
list for buffers that are backed by system pages (not VRAM). I guess 
what you would want to do is to replace the VRAM lru list with a 
priority queue where bos are continously sorted based on hotness.
As long as you obey the locking rules:
*) Locking order is bo::reserve -> lru-lock
*) When walking the queue with the lru-lock held, you must therefore 
tryreserve if you want to reserve an object on the queue
*) bo:s need to be removed from the queue as soon as they are reserved
*) Don't remove a bo from the queue unless it is reserved
Nothing stops you from doing this in the driver, but OTOH if this ends 
up being useful for other drivers I'd prefer we put it into TTM.

Thanks,
Thomas



>
> - Lauri
>
> * github.com/clbr/jamkthesis

  reply	other threads:[~2013-12-05 10:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05  9:36 TTM's role in score-based eviction Lauri Kasanen
2013-12-05 10:26 ` Thomas Hellstrom [this message]
2013-12-05 15:49   ` Jerome Glisse
2013-12-05 16:22     ` Maarten Lankhorst
2013-12-05 16:45       ` Jerome Glisse
2013-12-09 17:28         ` Daniel Vetter
2013-12-09 19:32           ` Thomas Hellstrom
2013-12-09 19:28 ` Marek Olšák
2013-12-09 20:30   ` Lauri Kasanen
2013-12-09 22:45     ` Marek Olšák
2013-12-10  0:49       ` Michel Dänzer
2013-12-10 11:03         ` Maarten Lankhorst
2013-12-11  3:04           ` Michel Dänzer
2013-12-11  7:57             ` Maarten Lankhorst
2013-12-11  8:36               ` Thomas Hellstrom
2013-12-11 11:35             ` Lauri Kasanen
2013-12-11 14:46               ` Thomas Hellstrom
2013-12-11 16:29                 ` Lauri Kasanen
2013-12-10 11:14         ` Marek Olšák
2013-12-10 11:59       ` Lauri Kasanen
2013-12-10 13:18         ` Marek Olšák

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=52A054E6.4060908@vmware.com \
    --to=thellstrom@vmware.com \
    --cc=cand@gmx.com \
    --cc=dri-devel@lists.freedesktop.org \
    /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.