Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure

[vinayak menon <vinayakm.list@gmail.com>]

On Thu, Feb 2, 2017 at 9:31 PM, Michal Hocko <mhocko@kernel.org> 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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>