On Thu, Feb 2, 2017 at 9:31 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > Why would you like to chose and kill a task when the slab reclaim can > still make sufficient progres? Are you sure that the slab contribution > to the stats makes all the above happening? > I agree that a task need not be killed if sufficient progress is made in reclaiming memory say from slab. But here it looks like we have an impact because of just increasing the reclaimed without touching the scanned. It could be because of disimilar costs or not adding adding cost. I agree that vmpressure is only a reasonable estimate which does not already include few other costs, but I am not sure whether it is ok to add another element which further increases that disparity. We noticed this problem when moving from 3.18 to 4.4 kernel version. With the same workload, the vmpressure events differ between 3.18 and 4.4 causing the above mentioned problem. And with this patch on 4.4 we get the same results as in 3,18. So the slab contribution to stats is making a difference. >> This increases the memory pressure and >> finally result in late critical events, but by that time the task >> launch latencies are impacted. > > I have seen vmpressure hitting critical events really quickly but that > is mostly because the vmpressure uses only very simplistic > approximation. Usually the reclaim goes well, until you hit to dirty > or pinned pages. Then it can get really bad, so you can get from high > effectiveness to 0 pretty quickly. > -- > 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>
