All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lauri Kasanen <cand@gmx.com>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: TTM's role in score-based eviction
Date: Wed, 11 Dec 2013 13:35:12 +0200	[thread overview]
Message-ID: <20131211133512.ae5c3c2c.cand@gmx.com> (raw)
In-Reply-To: <1386731045.5680.29.camel@thor.local>

On Wed, 11 Dec 2013 12:04:05 +0900
Michel Dänzer <michel@daenzer.net> wrote:

> > 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.

We don't have that in the kernel. Only userspace has the accurate stats
on usage. If we instead modified userspace to pass these stats, it
would have the exact same issue of "what if somebody passes false data"?

Maarten:
> Well, the easiest solution is to make the score only count as penalty,
> and set buffers that don't have the meta-data to maximum score. This
> preserves current behavior for clients that aren't score aware.

No, this would be the exact opposite: it would pin the old-userspace
buffers, at the cost of possibly not letting proper-scored buffers in
VRAM.

Thomas:
> I agree with Michel that some mechanism needs to be in place to stop 
> user-space clients from effectively pinning buffers by giving them a certain > score.

I think the kernel just has to trust userspace on this. I can't think
of any way of not involving userspace, so if somebody really wants to
hack mesa to gain some fps advantage on a multiseat system, let them ;)

Basically, they already can hack mesa to pass invalid buffers to cause
a hang/crash the kernel. So we already trust userspace more than this
new functionality would.

> 2) If score is calculated in user-space, how are shared buffers handled?

Good question, I don't know yet.

- Lauri

  parent reply	other threads:[~2013-12-11 11:34 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
2013-12-11  7:57             ` Maarten Lankhorst
2013-12-11  8:36               ` Thomas Hellstrom
2013-12-11 11:35             ` Lauri Kasanen [this message]
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=20131211133512.ae5c3c2c.cand@gmx.com \
    --to=cand@gmx.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=michel@daenzer.net \
    /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.