linux-kernel - Re: [PATCH 34/49] gma500: the GEM and GTT code is device independant

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Oct 2011 10:48:19 -0700 (PDT)
From:	Hugh Dickins <hughd@...gle.com>
To:	Rob Clark <rob.clark@...aro.org>
cc:	Patrik Jakobsson <patrik.r.jakobsson@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>, greg@...ah.com,
	linux-kernel@...r.kernel.org
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@...gle.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/