Re: [PATCH] Export shmem_file_setup and shmem_getpage for DRM-GEM

["John Stoffel" <john@stoffel.org>]

>>>>> "Hugh" == Hugh Dickins <hugh@veritas.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