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

On Mon, 2008-08-04 at 19:39 +0100, Hugh Dickins wrote:

Well, I guess put the check on ->readpage into your code for now, and
by the time GEM gets into Linus's tree, we should have -EINVAL checks
on NULL filler() in __read_cache_page() and read_cache_page_async(),
so remove check at your end before final submission.

Sounds good to me.

I think you should drop the mark_page_accessed(): that's done in
read_cache_page_async() as part of the initial read_mapping_page().
But do it again when releasing if you think there's a good chance
that object will be wanted again shortly. set_page_dirty() if
modified by GPU, yes, that would still be needed.

I'll just remove it then; pages pulled from the GTT are unlikely to be
used soon.

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.

I ask because Rik & Lee have patches in -mm, trying to avoid long
scans of LRUs cluttered with unevictable pages. I've no idea
whether you're adding a lot or a little to that problem.

If the idea of 1GB of pinned memory doesn't scare you, then I don't see
a problem ;-)

--
keith.packard@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part