Re: [PATCH 34/49] gma500: the GEM and GTT code is deviceindependant

[Hugh Dickins]

On Sat, 15 Oct 2011, Rob Clark wrote:
> On Mon, Oct 10, 2011 at 1:37 PM, Hugh Dickins <hughd@xxxxxxxxxx> wrote:
> >
> > I haven't rushed to address the 4GB issue, but what I have in mind is
> > killing two-and-a-half birds with one stone, by putting a little cookie
> > into the swapper_space radix_tree when we free a swapcache page, that
> > specifies node/zone and hashes object/offset.
> 
> Without really knowing the details about how hard it would be to
> implement, it would solve one additional problem if we could have a
> per-mapping callback fxn for allocating pages.
> 
> At least on ARM (but I guess probably some other architectures too),
> we really want to avoid having a page mapped cachable in the kernel,
> and uncached/writecombine in userspace.  With a per-mapping page
> allocation fxn, we could do something like
> dma_alloc_coherant/writecombine (for example) to allocate backing
> pages for GEM buffers which are mmap'd to userspace as something other
> than cachable.

It feels to me like GEM is pulling shmem in an ever more alien direction:
these device constraints are so foreign to the nature of tmpfs; and
beyond my expertise, so that I'd be ever more likely to make the wrong
decisions (mixing swap and uncached pages? hmmm).

We ought to re-examine whether GEM should be using tmpfs at all, whether
it would be better served by its own filesystem or other infrastructure.

Really, the one reason for wanting tmpfs is to have the benefit of offload
to swap (and that is indeed a feature I wouldn't care to distribute around
to drivers).

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/