On 3/20/2018 4:59 PM, Minchan Kim wrote: > On Tue, Mar 20, 2018 at 04:22:36PM +0530, Vinayak Menon wrote: >>>> up few more times and doing shorter steals is better than kswapd stealing more in a single run. The latter >>>> does not better direct reclaims and causes thrashing too. >>> That's the tradeoff of kswapd aggressiveness to avoid high rate >>> direct reclaim. >> We can call it trade off only if increasing the aggressiveness of kswapd reduces the direct reclaims ? >> But as shown by the data I had shared, the aggressiveness does not improve direct reclaims. It is just causing >> unnecessary reclaim. i.e. a much lower low-high gap gives the same benefit on direct reclaims with far less >> reclaim. > Said again, it depends on workload. I can make simple test to break it easily. > >> > I don't think repeated app launching on android doesn't reflect real user > scenario. Anyone don't do that in real life except some guys want to show > benchmark result in youtube. Agree that user won't open apps continuously in sequence like the test does. But I believe it is very similar to what a user would do with the device. i.e. open an app, do something, switch to another app..then come back to previous app. The test tries to emulate the same. > About mmtests, what kinds of tests did you perform? So what's the result? > If you reduced thrashing, how much the test result is improved? > Every tests are improved? Need not vmstat but result from the benchmark. > Such wide testing would make more conviction. I had performed the multibuild test of mmtests (3G RAM). Results below. wsf-default wsf-this-patch multibuild time (secs) 7338 7186 workingset_refault 1228216 974074 (-20%) workingset_activate 292110 181789 (-37%) pgpgin 11307694 8678200 (-23%) allocstall 98 103 >> and also the mmtests shows the problem, and fixed by the patch, can we try to pick it and see if someone complains ? I see that >> there were other reports of this https://lkml.org/lkml/2017/11/24/167 . Do you suggest a tunable approach taken by the patch >> in that link ? So that varying use cases can be accommodated. I wanted to avoid a new tunable if some heuristic like the patch does >> just works. > Actually, I don't want to touch it unless we have more nice feedback > algorithm. > > Anyway, it's just my opinion. I did best effort to explain. I will > defer to maintainer. > > Thanks.
