On Wed, Nov 10, 2010 at 02:27:04PM +0000, Mel Gorman wrote: > Agreed. Any performance increase from THP is not likely to offset the > cost of lumpy reclaim. Exactly. Furthermore the improvement will still happen later by polling compaction once every 10 sec with khugepaged (this is also required in case some other guest or application quit releasing tons of ram maybe natively order 9 in the buddy without requiring any further compaction invocation). What the default should be I don't know, but I like a default that fails without causing swap storms. If you want the swap storms and to drop all ptes regardless of their young bits, you should ask explicitly for it I think. Anybody asking for high order allocation and pretending to succeed despite the anti-frag and movable pageblocks migrated with compaction aren't enough to succeed should be able to handle a full graceful failure like THP does by design (or worst case to return error to userland). As far as I can tell tg3 atomic order 2 allocation also provides for a graceful fallback for the same reason (however in new mainline it floods the dmesg with tons of printk, which it didn't used to with older kernels but it's not an actual regression). > Again agreed, I have no problem with lumpy reclaim being pushed aside. > I'm just less keen on it being disabled altogether. I have high hopes > for the series I'm working on that it can be extended slightly to suit > the needs of THP. Great. Well this is also why I disabled it with the smallest possible modification, to avoid stepping on your toes. > Nah, the first thing I did was eliminate being "my fault" :). It would > have surprised me because the patches in isolation worked fine. It > thought the inode changes might have had something to do with it so I > was chasing blind alleys for a while. Hopefully d065bd81 will prove to > be the real problem. Well I wasn't sure if you tested it already on that very workload, the patches weren't from you (even if you were in the signoffs). I mentioned it just in case, glad it's not related :). -- 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 policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>