TTM's role in score-based eviction
Maarten Lankhorst
maarten.lankhorst at canonical.com
Tue Dec 10 23:57:22 PST 2013
op 11-12-13 04:04, Michel Dänzer schreef:
> 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 at 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.
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.
More information about the dri-devel
mailing list