(2012/05/12 20:59), Hugh Dickins wrote: > The GMA500 GPU driver uses GEM shmem objects, but with a new twist: > the backing RAM has to be below 4GB. Not a problem while the boards > supported only 4GB: but now Intel's D2700MUD boards support 8GB, and > their GMA3600 is managed by the GMA500 driver. > > shmem/tmpfs has never pretended to support hardware restrictions on > the backing memory, but it might have appeared to do so before v3.1, > and even now it works fine until a page is swapped out then back in. > When read_cache_page_gfp() supplied a freshly allocated page for copy, > that compensated for whatever choice might have been made by earlier > swapin readahead; but swapoff was likely to destroy the illusion. > > We'd like to continue to support GMA500, so now add a new > shmem_should_replace_page() check on the zone when about to move > a page from swapcache to filecache (in swapin and swapoff cases), > with shmem_replace_page() to allocate and substitute a suitable page > (given gma500/gem.c's mapping_set_gfp_mask GFP_KERNEL | __GFP_DMA32). > > This does involve a minor extension to mem_cgroup_replace_page_cache() > (the page may or may not have already been charged); and I've removed > a comment and call to mem_cgroup_uncharge_cache_page(), which in fact > is always a no-op while PageSwapCache. > > Also removed optimization of an unlikely path in shmem_getpage_gfp(), > now that we need to check PageSwapCache more carefully (a racing caller > might already have made the copy). And at one point shmem_unuse_inode() > needs to use the hitherto private page_swapcount(), to guard against > racing with inode eviction. > > It would make sense to extend shmem_should_replace_page(), to cover > cpuset and NUMA mempolicy restrictions too, but set that aside for > now: needs a cleanup of shmem mempolicy handling, and more testing, > and ought to handle swap faults in do_swap_page() as well as shmem. > > Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> > --- Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
