From: "Michel Dänzer" <michel@daenzer.net>
To: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: TTM's role in score-based eviction
Date: Wed, 11 Dec 2013 12:04:05 +0900 [thread overview]
Message-ID: <1386731045.5680.29.camel@thor.local> (raw)
In-Reply-To: <52A6F503.7010301@canonical.com>
On Die, 2013-12-10 at 12:03 +0100, Maarten Lankhorst wrote:
> op 10-12-13 01:49, Michel Dänzer schreef:
> > On Mon, 2013-12-09 at 23:45 +0100, Marek Olšák wrote:
> >> On Mon, Dec 9, 2013 at 9:30 PM, Lauri Kasanen <cand@gmx.com> wrote:
> >>> Note that the hotness calculation will be in userspace, as only there
> >>> are the necessary counters available. So the finished hotness score
> >>> will be passed to the kernel, instead of sending all the necessary data
> >>> there. Ought to be less context switches that way.
> > Sounds like this could be abused by userspace though...
> Of all the worries that exist, this is a non-issue. Userspace can
> simply queue a lot of draw calls that take 1 second each through the
> normal command submission methods, why would it need to tweak some
> obscure number to cause some eviction?
That's not what I'm concerned about.
Consider e.g. a multiseat environment: Some users could patch their
userspace drivers such that their buffers are more likely to stay in
VRAM than those of other users.
I agree it's not a huge issue, I'm just saying we should try to make the
score calculation as much as possible based on the actual usage of the
buffers instead of on meta data provided by userspace.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2013-12-11 3:04 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
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 [this message]
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=1386731045.5680.29.camel@thor.local \
--to=michel@daenzer.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=maarten.lankhorst@canonical.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.