On Fri, Feb 26, 2016 at 08:50:15PM +0100, Andrea Arcangeli wrote: > Hello Mel, > > On Fri, Feb 26, 2016 at 11:13:16AM +0000, Mel Gorman wrote: > > 1. By default, "madvise" and direct reclaim/compaction for applications > > that specifically requested that behaviour. This will avoid breaking > > MADV_HUGEPAGE which you mentioned in a few places > > Defragging memory synchronously only under madvise is fine with me. > I think this is a sensible default though. As you pointed out, those applications specifically requested it and a delay *should* be acceptable. If not, then it's a one-liner to change the behaviour. > > 2. "never" will never reclaim anything and was the default behaviour of > > version 1 but will not be the default in version 2. > > 3. "defer" will wake kswapd which will reclaim or wake kcompactd > > whichever is necessary. This is new but avoids stalls while helping > > khugepaged do its work quickly in the near future. > > This is an kABI visible change, but it should be ok. I'm not aware of > any program that parses that file and could get confused. > Neither am I but it'll be a wait and see approach unfortunately to see do I get the dreaded "you broke an ABI that applications depend upon" report. > "defer" sounds an interesting default option if it could be made to > work better. > I was tempted to set it but given that there was a host of reclaim-related bugs recently I backed off. For example, the last three releases has a serious bug whereby NUMA machines swapped heavily and no one reported it (or I missed it). There is still one excessive reclaiming bug open that has a potential patch that hasn't been tested so that's still an issue. I didn't want to muddy the waters further. > > 4. "always" will direct reclaim/compact just like todays behaviour > > I suspect there are a number of apps that took advantage of the > "always" setting without realizing it, but we only could notice the > ones that don't. Agreed but in itself, it'll be interesting to see if anyone notices. With the new default, applications still get huge pages in a lot of cases. It'll be interesting to report if someone complains about long-term behaviour where THP utilisation is lower for periods of time until khugepaged recovers it. > In any case those apps can start to call > MADV_HUGEPAGE if they don't already and that will provide a definitive > fix. Yes or else they set the tunable to always and carry on. > With this approach MADV_HUGEPAGE will provide the same > reliability in allocation as before so there will be no problem then. > Yes. As I believe your concerns have been addressed, can I get an ack on this patch? -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>