From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH] mm: Work around Intel SNB GTT bug with some physical pages. Date: Tue, 8 May 2012 19:23:52 +0200 Message-ID: <20120508172352.GQ4802@phenom.ffwll.local> References: <1336432421-17972-1-git-send-email-marcheu@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Linus Torvalds , rob.clark@linaro.org Cc: =?iso-8859-1?Q?St=E9phane?= Marchesin , olofj@chromium.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Tue, May 08, 2012 at 08:25:38AM -0700, Linus Torvalds wrote: > On Mon, May 7, 2012 at 4:13 PM, St=E9phane Marchesin wrote: > > > > In the end, I came up with the ugly workaround of just leaking the > > offending pages in shmem.c. >=20 > Don't leak it. >=20 > Instead, add it to some RCU list, and free it using RCU. Or some > one-second timer or something. >=20 > That kind of approach should guarantee that it >=20 > (a) gets returned to the system >=20 > but >=20 > (b) the returning to the system gets delayed sufficiently that if th= e > i915 driver is doing lots of allocations it will be getting other > pages. >=20 > Hmm? The problem is also that this only affects Sandybdrige gpus, so we'd ne= ed to funnel this down to shmfs somehow ... Rob Clarke from Linaro will be working on a gemfs to make backing storage allocation more flexible - t= hey need that to support some arm gpus. That way round we wouldn't need to = put some ugly drm/i915 stuff into core shmfs. Rob? -Daniel --=20 Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48