Messages in this thread | | | Date | Sun, 9 Oct 2011 22:15:00 +0200 | Subject | Re: [PATCH 34/49] gma500: the GEM and GTT code is device independant | From | Patrik Jakobsson <> |
| |
On Mon, Jul 11, 2011 at 7:49 PM, Hugh Dickins wrote: > On Mon, 11 Jul 2011, Alan Cox wrote: >> > Your <4GB pages won't get swapped out while they're pinned. But can >> > it happen that they'd be unpinned, swapped out, swapped back in >4GB >> > pages, then cause trouble for you when needed again? >> >> It does look that way, in which case that will eventually need fixing. At >> the moment you can't put enough memory into a device using these chips >> but that won't always be true I imagine. > > Thanks, I won't worry about it at this moment, but we'd better not forget. > > If it's easy for you to include a WARN_ON_ONCE check (perhaps > on page_to_pfn(page)), that may be worth doing to remind us. > > It's a bit sad to learn this requirement just after I'd completed > removing the readpage copying code, and a bit strange to have shmem > confined by hardware constraints; but I guess that's what we took on > when we opened it up to GEM. > > It will probably make sense for me to add synchronous migration when > a shmem swap page is found not to match the contraints wanted by the > mapping it goes into: mainly for NUMA, but covering your case too. > > Hugh
I think we need to revisit this problem. On 3.1-rc4 with some of my own changes I've just triggered read_cache_page_gfp in psb_gtt_attach_pages when trying to set a resolution that doesn't fit in stolen memory. Replacing it with shmem_read_mapping_page seems to work but how do we go about solving the >4GB issue? Is it ok for now to just use shmem_read_mapping_page or did any of you have a better solution?
Thanks Patrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |