On Thu, Mar 16, 2017 at 03:34:03PM +0800, Aaron Lu wrote: > On Wed, Mar 15, 2017 at 05:28:43PM +0100, Michal Hocko wrote: > ... ... > > After all the amount of the work to be done is the same we just risk > > more lock contentions, unexpected CPU usage etc. > > I start to realize this is a good question. > > I guess max_active=4 produced almost the best result(max_active=8 is > only slightly better) is due to the test box is a 4 node machine and > therefore, there are 4 zone->lock to contend(let's ignore those tiny > zones only available in node 0). > > I'm going to test on a EP to see if max_active=2 will suffice to produce > a good enough result. If so, the proper default number should be the > number of nodes. Here are test results on 2 nodes EP with 128GiB memory, test size 100GiB. max_active time vanilla 2.971s ±3.8% 2 1.699s ±13.7% 4 1.616s ±3.1% 8 1.642s ±0.9% So 4 gives best result but 2 is probably good enough. If the size each worker deals with is changed from 1G to 2G: max_active time 2 1.605s ±1.7% 4 1.639s ±1.2% 8 1.626s ±1.8% Considering that we are mostly improving for memory intensive apps, the default setting should probably be: max_active = node_number with each worker freeing 2G memory. -- 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>
