On Mon, May 16, 2016 at 11:56:32PM +0900, Minchan Kim wrote: > On Mon, May 16, 2016 at 05:29:00PM +0300, Kirill A. Shutemov wrote: > > > Kirill, > > > You wanted to test non-HW access bit system and I did. > > > What's your opinion? > > > > Sorry, for late response. > > > > My patch is incomlete: we need to find a way to not mark pte as old if we > > handle page fault for the address the pte represents. > > I'm sure you can handle it but my point is there wouldn't be a big gain > although you can handle it in non-HW access bit system. Okay, let's be > more clear because I don't have every non-HW access bit architecture. > At least, current mobile workload in ARM which I have wouldn't be huge > benefit. > I will say one more. > I tested the workload on quad-core system and core speed is not so slow > compared to recent other mobile phone SoC. Even when I tested the benchmark > without pte_mkold, the benefit is within noise because storage is really > slow so major fault is dominant factor. So, I decide test storage from eMMC > to eSATA. And then finally, I manage to see the a little beneift with > fault_around without pte_mkold. > > However, let's consider side-effect aspect from fault_around. > > 1. Increase slab shrinking compard to old > 2. high level vmpressure compared to old > > With considering that regressions on my system, it's really not worth to > try at the moment. > That's why I wanted to disable fault_around as default in non-HW access > bit system. Feel free to post such patch. I guess it's reasonable. > > Once this will be done, the number of page faults shouldn't be higher with > > fault-around enabled even on machines without hardware accessed bit. This > > will address performance regression with the patch on such machines. > > Although you solves that, I guess the benefit would be marginal in > some architectures but we should solve above side-effects. > > > > > I'll try to find time to update the patch soon. > > I hope you can solve above those regressions as well. The patch is posted. Please test. -- Kirill A. Shutemov -- 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>