On Tue, Mar 29, 2011 at 1:45 PM, Andrea Arcangeli <aarcange@xxxxxxxxxx> wrote: > On Tue, Mar 29, 2011 at 01:35:24PM -0700, Ying Han wrote: >> In page reclaim, I would like to discuss on the magic "8" * >> high_wmark() in balance_pgdat(). I recently found the discussion on >> thread "too big min_free_kbytes", where I didn't find where we proved >> it is still a problem or not. This might not need reserve time slot, >> but something I want to learn more on. > > That is merged in 2.6.39-rc1. It's hopefully working good enough. We > still use high+balance_gap but the balance_gap isn't high*8 anymore. I > still think the balance_gap may as well be zero but the gap now is > small enough (not 600M on 4G machine anymore) that it's ok and this > was a safer change. > > This is an LRU ordering issue to try to keep the lru balance across > the zones and not just rotate a lot a single one. I think it can be > covered in the LRU ordering topic too. But we could also expand it to > a different slot if we expect too many issues to showup in that > slot... Hugh what's your opinion? Yes, that is what I got from the thread discussion and thank you for confirming that. Guess my question is : Do we need to do balance across zones by giving the fact that each zone does its own balancing? What is the problem we saw without doing the cross-zone balancing? I don't have data to back-up either way, and that is something I am interested too :) --Ying > > The subtopics that comes to mind for that topic so far would be: > > - reclaim latency > - compaction issues (Mel) > - lru ordering altered by compaction/migrate/khugepaged or other > features requiring lru page isolation (Minchan) > - lru rotation balance across zones in kswapd (balance_gap) (Ying) > -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href