From: Lauri Kasanen <cand@gmx.com>
To: Thomas Hellstrom <thellstrom@vmware.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: TTM's role in score-based eviction
Date: Wed, 11 Dec 2013 18:29:20 +0200 [thread overview]
Message-ID: <20131211182920.ddfa54d0.cand@gmx.com> (raw)
In-Reply-To: <52A87ADD.30805@vmware.com>
On Wed, 11 Dec 2013 15:46:53 +0100
Thomas Hellstrom <thellstrom@vmware.com> wrote:
> > 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.
>
> Yes, but these are two different things. Letting user-space pin buffers
> by design is building in a software DOS in the kernel.
> I don't think even Microsoft is allowing this, and AFAICT we've avoided
> that since the very dawn of kernel buffer management.
>
> Not having a perfect command stream parser or proper GPU hang recovery
> mechanism is something else, and something we wish
> to have but don't at the moment.
>
> Allowing a new type of DOS just because we have other flaws isn't moving
> things forward, but i guess in the end it's your choice.
The worst case with the scoring is that a new client will work
somewhat slower than it otherwise would. I wouldn't call this a DOS.
Instead I would compare it to nice levels. Still, I agree with your
concern that a user could disturb another user. This wouldn't be an
issue within a single user environment, as the user obviously wanted
it if he went that far.
Perhaps we could solve that by taking the process's UID into account
inside the kernel. If there are multiple UIDs with 3d processes
running, reserve a chunk of VRAM for each?
- Lauri
next prev parent reply other threads:[~2013-12-11 16:28 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
2013-12-11 14:46 ` Thomas Hellstrom
2013-12-11 16:29 ` Lauri Kasanen [this message]
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=20131211182920.ddfa54d0.cand@gmx.com \
--to=cand@gmx.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=thellstrom@vmware.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.