Re: [PATCH] mm, memcg: support memory.{min, low} protection in cgroup v1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yafang Shao writes:
While it may superficially work without it, I'm sceptical that simply adding
memory.low and memory.min to the v1 hierarchy is going to end up with
reasonable results under scrutiny, or a coherent system or API.

I have finished some simple stress tests, and the result are fine.
Would you pls give me some suggestion on how to test it if you think
there may be some issues ?

My concerns are about introducing an API that requires propagation of control into an API that doesn't delineate between using values for *propagation* and using values for *consumption*, and this becomes significantly more important when we're talking about something that necessitates active propagation of values like memory.{low,min}. That's one reason why I bring up concerns related to the fact that v1 allows processes in intermediate cgroups.

So again, I'm not expecting that anything necessarily technically goes wrong (hence my comment at the beginning), just that it doesn't necessarily compose to a reasonable thing to have in v1. My concerns are almost strictly about exposing this as an interface in an API that doesn't have qualities that make the end result reasonable.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux