From patchwork Tue Jun 30 11:20:19 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Wilson X-Patchwork-Id: 6695201 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id C33A0C05AC for ; Tue, 30 Jun 2015 11:20:33 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 01F26205CA for ; Tue, 30 Jun 2015 11:20:33 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 0DE9D2053A for ; Tue, 30 Jun 2015 11:20:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3565A6E473; Tue, 30 Jun 2015 04:20:31 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from fireflyinternet.com (mail.fireflyinternet.com [87.106.93.118]) by gabe.freedesktop.org (Postfix) with ESMTP id C36AD6E473 for ; Tue, 30 Jun 2015 04:20:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138; Received: from nuc-i3427.alporthouse.com (unverified [78.156.65.138]) by fireflyinternet.com (Firefly Internet (M1)) with ESMTP id 41669528-1500048 for multiple; Tue, 30 Jun 2015 12:20:30 +0100 Received: by nuc-i3427.alporthouse.com (sSMTP sendmail emulation); Tue, 30 Jun 2015 12:20:19 +0100 Date: Tue, 30 Jun 2015 12:20:19 +0100 From: Chris Wilson To: Daniel Vetter Message-ID: <20150630112019.GJ1381@nuc-i3427.alporthouse.com> Mail-Followup-To: Chris Wilson , Daniel Vetter , intel-gfx@lists.freedesktop.org, Imre Deak , Akash Goel References: <1435646226.20771.140.camel@akashgoe-desktop> <1435658288-31656-1-git-send-email-chris@chris-wilson.co.uk> <20150630105402.GQ30960@phenom.ffwll.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150630105402.GQ30960@phenom.ffwll.local> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Imre Deak , intel-gfx@lists.freedesktop.org, Akash Goel Subject: Re: [Intel-gfx] [PATCH] drm/i915: Migrate stolen objects before hibernation X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Jun 30, 2015 at 12:54:02PM +0200, Daniel Vetter wrote: > > + list_add(&obj->stolen_link, &to_i915(dev)->mm.stolen_list); > > + > > + /* By default, treat the contexts of stolen as volatile. If the object > > + * must be saved across hibernation, then the caller must take > > + * action and flag it as WILLNEED. > > + */ > > + obj->madv = I915_MADV_DONTNEED; > > Won't this interfere with autoreclaim of stolen objects (to make room for > users which really need it like fbc) which are still in use by userspace? > I think we need a new madv flag for "REAP_ON_HIBERNATE" or something > similar. Otherwise this is way too surprising for userspace. I didn't like this much either, and even in the hibernate loop, we confuse userspace madv with internal objects. I went with a new So that we could easily distinguish the internal objects from userspace. -Chris diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index ec10f389886e..c8ea71713ab8 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2064,6 +2064,12 @@ struct drm_i915_gem_object { * Advice: are the backing pages purgeable? */ unsigned int madv:2; + /** + * Whereas madv is for userspace, there are certain situations + * where we want I915_MADV_DONTNEED behaviour on internal objects + * without conflating the userspace setting. + */ + unsigned int nonvolatile:1; (I don't like the double negative, but it's better than int _volatile:1;)