From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lauri Kasanen Subject: Re: TTM's role in score-based eviction Date: Wed, 11 Dec 2013 18:29:20 +0200 Message-ID: <20131211182920.ddfa54d0.cand@gmx.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> <52A87ADD.30805@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by gabe.freedesktop.org (Postfix) with ESMTP id 569BAFB94F for ; Wed, 11 Dec 2013 08:28:33 -0800 (PST) Received: from Valinor ([84.248.177.169]) by mail.gmx.com (mrgmx002) with ESMTPA (Nemesis) id 0Lxxw4-1VVpyl0j12-015L1T for ; Wed, 11 Dec 2013 17:28:31 +0100 In-Reply-To: <52A87ADD.30805@vmware.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Thomas Hellstrom Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Wed, 11 Dec 2013 15:46:53 +0100 Thomas Hellstrom 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