• Fengguang Wu's avatar
    mm: share PG_readahead and PG_reclaim · fe3cba17
    Fengguang Wu authored
    Share the same page flag bit for PG_readahead and PG_reclaim.
    
    One is used only on file reads, another is only for emergency writes.  One
    is used mostly for fresh/young pages, another is for old pages.
    
    Combinations of possible interactions are:
    
    a) clear PG_reclaim => implicit clear of PG_readahead
    	it will delay an asynchronous readahead into a synchronous one
    	it actually does _good_ for readahead:
    		the pages will be reclaimed soon, it's readahead thrashing!
    		in this case, synchronous readahead makes more sense.
    
    b) clear PG_readahead => implicit clear of PG_reclaim
    	one(and only one) page will not be reclaimed in time
    	it can be avoided by checking PageWriteback(page) in readahead first
    
    c) set PG_reclaim => implicit set of PG_readahead
    	will confuse readahead and make it restart the size rampup process
    	it's a trivial problem, and can mostly be avoided by checking
    	PageWriteback(page) first in readahead
    
    d) set PG_readahead => implicit set of PG_reclaim
    	PG_readahead will never be set on already cached pages.
    	PG_reclaim will always be cleared on dirtying a page.
    	so not a problem.
    
    In summary,
    	a)   we get better behavior
    	b,d) possible interactions can be avoided
    	c)   racy condition exists that might affect readahead, but the chance
    	     is _really_ low, and the hurt on readahead is trivial.
    
    Compound pages also use PG_reclaim, but for now they do not interact with
    reclaim/readahead code.
    Signed-off-by: default avatarFengguang Wu <wfg@mail.ustc.edu.cn>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    fe3cba17
page_alloc.c 106 KB