Re: TTM's role in score-based eviction

[Thomas Hellstrom <thellstrom@vmware.com>]

On 12/11/2013 12:35 PM, Lauri Kasanen wrote:
> 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.

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.

Thanks,
Thomas