From: Thomas Hellstrom <thomas@shipmail.org>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: Jerome Glisse <jglisse@redhat.com>, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction
Date: Thu, 29 Nov 2012 09:41:34 +0100 [thread overview]
Message-ID: <50B71FBE.7050101@shipmail.org> (raw)
In-Reply-To: <CAH3drwZUY60FCcSVXAz6w=aV1eYo5Mt7ZfNDRyM2VZv4kBFQOA@mail.gmail.com>
On 11/29/2012 12:24 AM, Jerome Glisse wrote:
> On Wed, Nov 28, 2012 at 6:18 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
>> On 11/28/2012 04:58 PM, j.glisse@gmail.com wrote:
>>> From: Jerome Glisse <jglisse@redhat.com>
>>>
>>> This patch add a minimum residency time configurable for each memory
>>> pool (VRAM, GTT, ...). Intention is to avoid having a lot of memory
>>> eviction from VRAM up to a point where the GPU pretty much spend all
>>> it's time moving things in and out.
>>
>> This patch seems odd to me.
>>
>> It seems the net effect is to refuse evictions from VRAM and make buffers go
>> somewhere else, and that makes things faster?
>>
>> Why don't they go there in the first place instead of trying to force them
>> into VRAM,
>> when VRAM is full?
>>
>> /Thomas
> It's mostly a side effect of cs and validating with each cs, if boA is
> in cs1 and not in cs2 and boB is in cs1 but not in cs2 than boA could
> be evicted by cs2 and boB moved in, if next cs ie cs3 is like cs1 then
> boA move back again and boB is evicted, then you get cs4 which
> reference boB but not boA, boA get evicted and boB move in ... So ttm
> just spend its time doing eviction but he doing so because it's ask by
> the driver to do so. Note that what is costly there is not the bo move
> in itself but the page allocation.
Yes, this is the cause of the trashing, but that was not what I asked.
What your patch is doing is looking at the last recently used bo, to
check if it has been
resident for at least 500ms. Otherwise it refuses eviction for *all*
buffers of that memory type.
This means new buffers can't fit in VRAM, they need to go somewhere
else. Perhaps TT?
So my question was. If VRAM is full, instead of starting to evict, why
not put new buffers in TT, so that
placement(GEM_DOMAIN_VRAM) = VRAM | TT // Prefer VRAM but allow TT
before starting to evict.
busy_placement(GEM_DOMAIN_VRAM) = TT | VRAM // *If* we need to evict,
prefer evicting TT, then evict VRAM)
This will more or less mimic carmack's algorithm by using TT as his "MRU
scratch space".
And as a side note, your patch breaks
ttm_bo_force_list_clean()
which should be used at GPU memory exhaustion to avoid OOM due to
fragmentation and for those drivers that
implement VRAM cleanup on VT switch and / or suspend / hibernation.
/Thomas
next prev parent reply other threads:[~2012-11-29 8:41 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-28 15:58 [RFC] drm/ttm: add minimum residency constraint for bo eviction j.glisse
2012-11-28 15:58 ` [PATCH] " j.glisse
2012-11-28 23:18 ` Thomas Hellstrom
2012-11-28 23:24 ` Jerome Glisse
2012-11-28 23:44 ` Alan Swanson
2012-11-29 0:01 ` Jerome Glisse
2012-11-29 2:15 ` Marek Olšák
2012-11-29 8:04 ` Thomas Hellstrom
2012-11-29 12:52 ` Marek Olšák
2012-11-29 20:33 ` Thomas Hellstrom
2012-11-29 21:58 ` Marek Olšák
2012-11-30 8:38 ` Thomas Hellstrom
2012-11-30 9:39 ` Asynchronous eviction [WAS Re: [PATCH] drm/ttm: add minimum residency constraint for bo eviction] Thomas Hellstrom
2012-11-30 16:30 ` Jerome Glisse
2012-11-30 17:08 ` Thomas Hellstrom
2012-11-30 17:18 ` Jerome Glisse
2012-11-30 17:43 ` Thomas Hellstrom
2012-11-30 18:07 ` Jerome Glisse
2012-11-30 18:31 ` Thomas Hellstrom
2012-11-30 19:25 ` Jerome Glisse
2012-11-30 20:35 ` Thomas Hellstrom
2012-11-30 21:07 ` Jerome Glisse
2012-11-30 21:36 ` Thomas Hellstrom
2012-11-30 22:02 ` Jerome Glisse
2012-11-29 8:41 ` Thomas Hellstrom [this message]
2012-11-29 15:50 ` [PATCH] drm/ttm: add minimum residency constraint for bo eviction Jerome Glisse
2012-11-28 21:51 ` [RFC] " Marek Olšák
2012-11-28 23:18 ` Jerome Glisse
2012-11-29 9:18 ` Thomas Hellstrom
2012-11-29 9:28 ` Michel Dänzer
2012-11-29 9:48 ` Thomas Hellstrom
2012-11-29 19:20 ` Marek Olšák
2012-11-29 19:36 ` Jerome Glisse
2012-11-29 20:40 ` Thomas Hellstrom
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=50B71FBE.7050101@shipmail.org \
--to=thomas@shipmail.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=j.glisse@gmail.com \
--cc=jglisse@redhat.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.