From: Daniel Vetter <daniel@ffwll.ch>
To: Linus Torvalds <torvalds@linux-foundation.org>, rob.clark@linaro.org
Cc: "Stéphane Marchesin" <marcheu@chromium.org>,
olofj@chromium.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] mm: Work around Intel SNB GTT bug with some physical pages.
Date: Tue, 8 May 2012 19:23:52 +0200 [thread overview]
Message-ID: <20120508172352.GQ4802@phenom.ffwll.local> (raw)
In-Reply-To: <CA+55aFyd08=eemQsUFvtjerEVQdznhe647w4PmSrPkkEvjNuzg@mail.gmail.com>
On Tue, May 08, 2012 at 08:25:38AM -0700, Linus Torvalds wrote:
> On Mon, May 7, 2012 at 4:13 PM, Stéphane Marchesin <marcheu@chromium.org> wrote:
> >
> > In the end, I came up with the ugly workaround of just leaking the
> > offending pages in shmem.c.
>
> Don't leak it.
>
> Instead, add it to some RCU list, and free it using RCU. Or some
> one-second timer or something.
>
> That kind of approach should guarantee that it
>
> (a) gets returned to the system
>
> but
>
> (b) the returning to the system gets delayed sufficiently that if the
> i915 driver is doing lots of allocations it will be getting other
> pages.
>
> Hmm?
The problem is also that this only affects Sandybdrige gpus, so we'd need
to funnel this down to shmfs somehow ... Rob Clarke from Linaro will be
working on a gemfs to make backing storage allocation more flexible - they
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
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2012-05-08 17:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-07 23:13 [PATCH] mm: Work around Intel SNB GTT bug with some physical pages Stéphane Marchesin
2012-05-07 23:57 ` Andi Kleen
2012-05-08 6:53 ` Dave Airlie
2012-05-08 7:21 ` Daniel Vetter
2012-05-08 15:25 ` Linus Torvalds
2012-05-08 17:23 ` Daniel Vetter [this message]
2012-05-08 18:03 ` Rob Clark
2012-05-08 21:57 ` Hugh Dickins
2012-05-09 8:56 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120508172352.GQ4802@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcheu@chromium.org \
--cc=olofj@chromium.org \
--cc=rob.clark@linaro.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox