From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [PATCH] prime_self_import: Assure no pending requests before object counting Date: Fri, 1 Nov 2013 11:44:40 -0700 Message-ID: <20131101184440.GA3866@bwidawsk.net> References: <1383310422-30702-1-git-send-email-oscar.mateo@intel.com> <20131101160817.GM4167@phenom.ffwll.local> <20131101161851.GB8592@bwidawsk.net> <20131101184259.GQ4167@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.bwidawsk.net (bwidawsk.net [166.78.191.112]) by gabe.freedesktop.org (Postfix) with ESMTP id 2B153EEFD5 for ; Fri, 1 Nov 2013 11:44:45 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20131101184259.GQ4167@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Fri, Nov 01, 2013 at 07:42:59PM +0100, Daniel Vetter wrote: > On Fri, Nov 01, 2013 at 09:18:51AM -0700, Ben Widawsky wrote: > > On Fri, Nov 01, 2013 at 05:08:17PM +0100, Daniel Vetter wrote: > > > On Fri, Nov 01, 2013 at 12:53:42PM +0000, oscar.mateo@intel.com wrote: > > > > From: Oscar Mateo > > > > > > > > We don't want a previously used object to be freed in the middle of a > > > > before/after object counting operation (or we would get a "-1 objects > > > > leaked" message). We have seen this happening, e.g., when a context > > > > from a previous run dies, but its backing object is alive waiting for > > > > a retire_work to kick in. > > > > > > > > Signed-off-by: Oscar Mateo > > > > Cc: Ben Widawsky > > > > > > Nice catch. Should we do this in general as part of our gem_quiescent_gpu > > > helper? All i-g-t testcase are written under the assumption that they > > > completel own the gpu and that the gtt is completely empty besides the few > > > driver-allocated and pinned objects. So trying really hard to get rid of > > > any residual stuff sounds like a good idea. > > > > I was going to address this in the other mail thread.... in any case, I > > think not. I believe a separate helper is the way to go, and we should > > only call it when we absolutely want to. > > > > Though it's not the intention, I've seen many tests fail because of > > previous state, and I don't want to miss out on those in the future. It > > would also slow down the run unnecessarily further. > > We already do rather eregious stuff in quiescent. So I want hard numbers > on your claim that it slows down stuff further - there really shouldn't be > much at all to retire/evict. > -Daniel I don't like any of those arbitrary calls to quiescent either fwiw. Can't I make the same demand for data BEFORE we merge the patch that it doesn't slow anything down? -- Ben Widawsky, Intel Open Source Technology Center