[lkml]   [2019]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH REBASED] mm, memcg: Make scan aggression always exclude protection
Andrew Morton writes:
>Could you please provide more description of the effect this has upon
>userspace? Preferably in real-world cases. What problems were being
>observed and how does this improve things?

Sure! The previous patch's behaviour isn't so much problematic as it is just
not as featureful as it could be.

This change doesn't change the experience for the user in the normal case too
much. One benefit is that it replaces the (somewhat arbitrary) 100% cutoff with
an indefinite slope, which makes it easier to ballpark a memory.low value.

As well as this, the old methodology doesn't quite apply generically to
machines with varying amounts of physical memory. Let's say we have a top level
cgroup, workload.slice, and another top level cgroup, system-management.slice.
We want to roughly give 12G to system-management.slice, so on a 32GB machine we
set memory.low to 20GB in workload.slice, and on a 64GB machine we set
memory.low to 52GB. However, because these are relative amounts to the total
machine size, while the amount of memory we want to generally be willing to
yield to system.slice is absolute (12G), we end up putting more pressure on
system.slice just because we have a larger machine and a larger workload to
fill it, which seems fairly unintuitive. With this new behaviour, we don't end
up with this unintended side effect.

 \ /
  Last update: 2019-03-22 23:01    [W:0.146 / U:3.552 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site