On Fri, Oct 29, 2010 at 12:43 PM, Rik van Riel <riel@xxxxxxxxxx> wrote: > On 10/28/2010 10:45 PM, KAMEZAWA Hiroyuki wrote: > >> Hmm. Without flushing anywhere in memory reclaim path, a process which >> cause page fault and enter vmscan will not see his own recent access bit >> on >> pages in LRU ? > > Worse still, because kernel threads do a lazy mmu switch, even > page faulting in the process will not cause the TLB entries to > be flushed. > >> I think it should be flushed at least once.. > > A periodic flush may make sense. > > Maybe something along the lines of if the TLB has not been > flushed for over a second (we can see that in timer or scheduler > code), flush it? What happens if we don't flush TLB? It will make for old page to pretend young page. If it is, how does it affect reclaim? It makes for old page to promote into active list by page_check_references. Of couse, It's not good. But for it, we have to keep wrong TLB until moving head to tail in inactive list. It's very unlikely. That's because TLB is very smalll and the process will be switching out. If lumpy happens(ie, not waiting from head to tail in inactive list to hold a victim page), that's all right since we ignore young bit in lumpy case. I think it's no problem unless inactive list is very short. Remained one is kernel thread's lazy TLB flush. So how about flushing TLB in kswapd scheduled in? > -- > All rights reversed > -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>