linux-kernel - Re: [PATCH] Export shmem_file_setup and shmem

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]

Message-ID: <18583.47633.987143.236236@stoffel.org>
Date:	Mon, 4 Aug 2008 22:25:21 -0400
From:	"John Stoffel" <john@...ffel.org>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	Keith Packard <keithp@...thp.com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Christoph Hellwig <hch@...radead.org>,
	Eric Anholt <eric@...olt.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM

>>>>> "Hugh" == Hugh Dickins <hugh@...itas.com> writes:

Hugh> On Mon, 4 Aug 2008, Keith Packard wrote:
>> On Mon, 2008-08-04 at 19:39 +0100, Hugh Dickins wrote:
>> > For how long are these objects' pages pinned in memory like this?
>> 
>> Forever? The only reason an object would get unpinned would be on
>> eviction from the GTT, and objects will only be evicted if we fill the
>> aperture with other stuff. When we add a register_shrinker callback,
>> we'll also unpin pages at that point.
>> 
>> A busy system should have the GTT entirely full, and that will be
>> somewhere between 256MB and 1GB.

Hugh> Okay, thanks for the warning.  It sounds like the shrinker will
Hugh> be important, but we'll also need to mark those pages as
Hugh> unevictable while they're unshrunk.  

What about the onboard memory of graphics cards?  Isn't that where
Textures and such are stored as well?  So once something is loaded to
the card, shouldn't you be able to free it in system memory?  Or swap
it out ahead of time?  

Hugh> (Usually when drivers grab a large number of pages, they're not
Hugh> on any LRU to begin with: you're being nice by choosing
Hugh> swappable LRU pages - in the tmpfs case - but enough to upset
Hugh> the balance while they're not swappable.)  Offhand I can't say
Hugh> what will be the appropriate way to do that, it's something we
Hugh> need to revisit later (from your point of view it should amount
Hugh> to one function call or flag set somewhere, not any grand
Hugh> redesign).

I just wonder here, since GPUs are different from other drivers in
that (I assume) they are written too much more often than they are
read to, that they should hopefully be much more amenable to drop
behind semantics for pages they've been sent, to free system
resources.

Now I admit I am most probably smoking something which is clouding my
understanding, so feel free to ingore my comments.  

John
--
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/