On Fri, Nov 8, 2019 at 9:26 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
>
> On Thu 07-11-19 01:08:08, Yafang Shao wrote:
> > This patch introduces a new memory controller file memory.low.level,
> > which is used to set multiple levels memory.low protetion.
> > The valid value of memory.low.level is [0..3], meaning we support four
> > levels protection now. This new controller file takes effect only when
> > memory.low is set. With this new file, we can do page reclaim QoS on
> > different memcgs. For example, when the system is under memory pressure, it
> > will reclaim pages from the memcg with lower priority first and then higher
> > priority.
> >
> > - What is the problem in the current memory low proection ?
> > Currently we can set bigger memory.low protection on memcg with higher
> > priority, and smaller memory.low protection on memcg with lower priority.
> > But once there's no available unprotected memory to reclaim, the
> > reclaimers will reclaim the protected memory from all the memcgs.
> > While we really want the reclaimers to reclaim the protected memory from
> > the lower-priority memcgs first, and if it still can't meet the page
> > allocation it will then reclaim the protected memory from higher-priority
> > memdcgs. The logic can be displayed as bellow,
> > under_memory_pressure
> > reclaim_unprotected_memory
> > if (meet_the_request)
> > exit
> > reclaim_protected_memory_from_lowest_priority_memcgs
> > if (meet_the_request)
> > exit
> > reclaim_protected_memory_from_higher_priority_memcgs
> > if (meet_the_request)
> > exit
> > reclaim_protected_memory_from_highest_priority_memcgs
>
> Could you expand a bit more on the usecase please? Do you overcommit on
> the memory protection?
>
Hi Michal,
It doesn't matter it is overcommited or not, becuase there's a
effective low protection when it is overcommitted.
Also the real low level is effective low level, which makes it work in
the cgroup hierachy.
Let's expand the example in the comment above mem_cgroup_protected()
with memory.low.level.
*
* A A/memory.low = 2G A/memory.current = 6G,
A/memory.low.level = 1
* / / \ \
* BC DE B/memory.low = 3G B/memory.current = 2G B/memory.low.level = 2
* C/memory.low = 1G C/memory.current = 2G
C/memory.low.level = 1
* D/memory.low = 0 D/memory.current = 2G
D/memory.low.level = 3
* E/memory.low = 10G E/memory.current = 0
E/memory.low.level = 3
Suppose A is the targeted memory cgroup, the following memory
distribution is expected,
A/memory.current = 2G
B/memory.current = 2G (because it has a higher low.level than C)
C/memory.current = 0
D/memory.current = 0
E/memory.current = 0
While if C/memory.low.level = 2, then the result will be
A/memory.current = 2G
B/memory.current = 1.3G
C/memory.current = 0.6G
D/memory.current = 0
E/memory.current = 0
> Also why is this needed only for the reclaim protection? In other words
> let's say that you have more memcgs that are above their protection
> thresholds why should reclaim behave differently for them from the
> situation when all of them reach the protection? Also what about min
> reclaim protection?
>
If you don't set memory.low (and memory.min), then you don't care
about the page reclaim.
If you really care about the page reclaim, then you should set
memory.low (and memory.min) first,
and if you want to distinguish the protected memory, you can use
memory.low.level then.
The reason we don't want to use min reclaim protection is that it will
cause more frequent OOMs
and you have to do more work to prevent random OOM.
> > - Why does it support four-level memory low protection ?
> > Low priority, medium priority and high priority, that is the most common
> > usecases in the real life. So four-level memory low protection should be
> > enough. The more levels it is, the higher overhead page reclaim will
> > take. So four-level protection is really a trade-off.
>
> Well, is this really the case? Isn't that just a matter of a proper
> implementation? Starting an API with a very restricted input values
> usually tends to outdate very quickly and it is found unsuitable. It
> would help to describe how do you envision using those priorities. E.g.
> do you have examples of what kind of services workloads fall into which
> priority.
>
> That being said there are quite some gaps in the usecase description as
> well the interface design.
We have diffrent workloads running on one single server.
Some workloads are latency sensitive, while the others are not.
When there's resource pressure on this server, we expect this pressure
impact the latency sensitive workoad as little as possile,
and throttle the latency non-sensitve workloads.
memory.{low, min} can seperate the page caches to 'unevictable'
memory, protected memory and non-protected memory, but it can't
seperate different containers (workloads).
In the latency-sensive containers, there're also some non-impottant
page caches, e.g. some page cahes for the log file,
so it would better to reclaim log file pages first (unprotected
memory) then reclaim protected pages from latency-non-sensitve
containers, then reclaim the protected pages from latency-sensitve
containers.
Sometimes we have to restrict the user behavior.
The current design memory.{min, low} seprate the page caches into min
protected, low protected and non-protected, that seems outdate now,
but we can improve it.
So I don't think the four-level low protection will be a big problem.
Thanks
Yafang
