From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: TTM's role in score-based eviction Date: Wed, 11 Dec 2013 15:46:53 +0100 Message-ID: <52A87ADD.30805@vmware.com> References: <20131205113658.52c84991.cand@gmx.com> <20131209223005.a33d4312.cand@gmx.com> <1386636560.32592.109.camel@thor.local> <52A6F503.7010301@canonical.com> <1386731045.5680.29.camel@thor.local> <20131211133512.ae5c3c2c.cand@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by gabe.freedesktop.org (Postfix) with ESMTP id 43726FA958 for ; Wed, 11 Dec 2013 06:46:57 -0800 (PST) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 00986282C2 for ; Wed, 11 Dec 2013 06:46:56 -0800 (PST) Received: from zcs-prod-ext-mta-1.vmware.com (zcs-prod-ext-mta-1.vmware.com [10.113.62.223]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id F1429B0519 for ; Wed, 11 Dec 2013 06:46:55 -0800 (PST) Received: from zcs-prod-ext-mta-1.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTP id 1E5B9120030 for ; Wed, 11 Dec 2013 06:47:30 -0800 (PST) Received: from linlap1.kontor.shipmail.org (zimbra-prod-ext-proxy-vip.vmware.com [10.113.63.87]) by zcs-prod-ext-mta-1.vmware.com (Postfix) with ESMTPSA for ; Wed, 11 Dec 2013 06:47:29 -0800 (PST) In-Reply-To: <20131211133512.ae5c3c2c.cand@gmx.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 12/11/2013 12:35 PM, Lauri Kasanen wrote: > On Wed, 11 Dec 2013 12:04:05 +0900 > Michel D=E4nzer 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 cer= tain > 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