From: "Christian König" <deathsimple@vodafone.de>
To: dri-devel@lists.freedesktop.org
Subject: RFC: Some TTM patches
Date: Wed, 6 Apr 2016 11:12:01 +0200 [thread overview]
Message-ID: <1459933928-4663-1-git-send-email-deathsimple@vodafone.de> (raw)
Hi everyone,
attached are six TTM patches and one Amdgpu patch I came up with while working
on a new TTM feature.
The first patch is a bug fix. TTM was always waiting for on a BO to be idle
when initially creating it. Previously that didn't matter much because a newly
created BO should always be idle. But with the possibility of importing DMA-buf
reservation objects into a TTM BO that sometimes isn't the case any more.
Patches 2, 3 and 4 are just cleanups, e.g. removal of unused parameters and
variables.
Patches 5 and 6 now finally implement the new LRU features in TTM. Basically
we want to give the driver more fine grained control about the order in which
the BOs are added to the LRU.
For this patch number 5 implements an optional LRU removal callback, giving the
driver the chance to updates it's internal LRU handling as well.
Patch number 6 add two callback functions which return the list head after which
a BO should be inserted into the LRU. Default implementations for those are
provided and wired up in all drivers with this patch.
The Amdgpu patch now uses the new callbacks to implement a LRU order so that VM
page table BOs always come behind everything else. I actually don't intent to
commit this patch, but it was good for testing.
In the end we want to use this LRU order for allowing HSA applications to have
their BOs after the graphics allocations because preempting HSA processes under
resource shortage has a huge bunch of overhead.
Another use Alex suggested is to sort the BOs in the LRU by size. So that we
don't swap out a 200MB BO to make room for a 1MB allocation.
Please review and comment,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2016-04-06 9:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 9:12 Christian König [this message]
2016-04-06 9:12 ` [PATCH 1/7] drm/ttm: don't wait for BO on initial allocation Christian König
2016-04-06 16:06 ` Sinclair Yeh
2016-04-13 17:38 ` Christian König
2016-04-13 17:51 ` Sinclair Yeh
2016-04-06 9:12 ` [PATCH 2/7] drm/ttm: remove use_ticket parameter from ttm_bo_reserve Christian König
2016-04-06 9:12 ` [PATCH 3/7] drm/ttm: remove lazy parameter from ttm_bo_wait Christian König
2016-04-06 9:12 ` [PATCH 4/7] drm/ttm: remove unused validation sequence Christian König
2016-04-06 9:12 ` [PATCH 5/7] drm/ttm: add optional LRU removal callback v2 Christian König
2016-04-06 9:12 ` [PATCH 6/7] drm/ttm: implement LRU add callbacks v2 Christian König
2016-04-06 9:12 ` [PATCH 7/7] drm/amdgpu: prefer VM page tables over normal BOs Christian König
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=1459933928-4663-1-git-send-email-deathsimple@vodafone.de \
--to=deathsimple@vodafone.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox