Messages in this thread | | | Date | Mon, 17 Oct 2011 10:48:19 -0700 (PDT) | From | Hugh Dickins <> | Subject | Re: [PATCH 34/49] gma500: the GEM and GTT code is device independant |
| |
On Sat, 15 Oct 2011, Rob Clark wrote: > On Mon, Oct 10, 2011 at 1:37 PM, Hugh Dickins <hughd@google.com> 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
| |