Re: [RFC PATCH 0/3] Cgroup-based THP control

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

 



gutierrez.asier@xxxxxxxxxxxxxxxxxxx writes:
New memcg files are exposed: memory.thp_enabled and memory.thp_defrag, which
have completely the same format as global THP enabled/defrag.

cgroup controls exist because there are things we want to do for an entire class of processes (group OOM, resource control, etc). Enabling or disabling some specific setting is generally not one of them, hence why we got rid of things like per-cgroup vm.swappiness. We know that these controls do not compose well and have caused a lot of pain in the past. So my immediate reaction is a nack on the general concept, unless there's some absolutely compelling case here.

I talked a little at Kernel Recipes last year about moving away from sysctl and other global interfaces and making things more granular. Don't get me wrong, I think that is a good thing (although, of course, a very large undertaking) -- but it is a mistake to overload the amount of controls we expose as part of the cgroup interface.

I am up for thinking overall about how we can improve the state of global tunables to make them more granular overall, but this can't set a precedent as the way to do it.




[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