On Fri 20-05-16 16:26:24, Minchan Kim wrote: > On Fri, May 20, 2016 at 08:39:17AM +0200, Michal Hocko wrote: > > On Fri 20-05-16 09:21:55, Minchan Kim wrote: > > [...] > > > I think other important thing we should consider is how the THP page is likely > > > to be hot without split in a short time like KSM is doing double checking to > > > merge stable page. Of course, it wouldn't be easyI to implement but I think > > > algorithm is based on such *hotness* basically and then consider the number > > > of max_swap_ptes. IOW, I think we should approach more conservative rather > > > than optimistic because a page I/O overhead by wrong choice could be bigger > > > than benefit of a few TLB hit. > > > If we approach that way, maybe we don't need to detect memory pressure. > > > > > > For that way, how about raising bar for swapin allowance? > > > I mean now we allows swapin > > > > > > from > > > 64 pages below swap ptes and 1 page young in 512 ptes > > > to > > > 64 pages below swap ptes and 256 page young in 512 ptes > > > > I agree that the current 1 page threshold for collapsing is way too > > optimistic. Same as the defaults we had for the page fault THP faulting > > which has caused many issues. So I would be all for changing it. I do > > I don't know we should change all but if we change it for THP faulting, > I believe THP swapin should be more conservative value rather than THP > faulting because cost of THP swapin collapsing would be heavier. > > > not have good benchmarks to back any "good" number unfortunately. So > > such a change would be quite arbitrary based on feeling... If you have > > some workload where collapsing THP pages causes some real issues that > > would be great justification though. > > Hope to have but our products never have turned on THP. :( > I just wanted to say current problem and suggestion so a THP guy > can have an interest on that. > If it's not worth to do, simple igonore. I guess this is worth changing I am just not sure about the justification > > That being said khugepaged_max_ptes_none = HPAGE_PMD_NR/2 sounds like a > > max_ptes_none? Not sure I understand what you mean here. -- Michal Hocko 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>