On Tue, Sep 24, 2019 at 03:30:16PM +0200, Michal Hocko wrote: > On Tue 24-09-19 15:36:42, Hillf Danton wrote: > > > > On Mon, 23 Sep 2019 21:28:34 Michal Hocko wrote: > > > > > > On Mon 23-09-19 21:04:59, Hillf Danton wrote: > > > > > > > > On Thu, 19 Sep 2019 21:32:31 +0800 Michal Hocko wrote: > > > > > > > > > > On Thu 19-09-19 21:13:32, Hillf Danton wrote: > > > > > > > > > > > > Currently memory controler is playing increasingly important role in > > > > > > how memory is used and how pages are reclaimed on memory pressure. > > > > > > > > > > > > In daily works memcg is often created for critical tasks and their pre > > > > > > configured memory usage is supposed to be met even on memory pressure. > > > > > > Administrator wants to make it configurable that the pages consumed by > > > > > > memcg-B can be reclaimed by page allocations invoked not by memcg-A but > > > > > > by memcg-C. > > > > > > > > > > I am not really sure I understand the usecase well but this sounds like > > > > > what memory reclaim protection in v2 is aiming at. > > > > > > > > Please describe the usecase. > > > > > It is for quite a while that task-A has been able to preempt task-B for > > cpu cycles. IOW the physical resource cpu cycles are preemptible. > > > > Are physical pages are preemptible too in the same manner? > > Nope without priority defined for pages currently (say the link between > > page->nice and task->nice). > > > > The slrp is added for memcg instead of nice because 1) it is only used > > in the page reclaiming context (in memcg it is soft limit reclaiming), > > and 2) it is difficult to compare reclaimer and reclaimee task->nice > > directly in that context as only info about reclaimer and lru page is > > available. > > > > Here task->nice is replaced with memcg->slrp in order to do page > > preemption, PP. There is no way for task-A to PP task-B, but the > > group containing task-A can PP the group containing task-B. > > That preemption needs code within 100 lines as you see on top of > > the current memory controller framework. > > This is exactly what the reclaim protection in memcg v2 is meant to be > used for. Also soft limit reclaim is absolutely terrible to achieve that > because it is just too gross to result in any smooth experience (just > have a look how it is doing priority 0 scannig!). > > I am not going to even go further wrt the implementation because I > belive the priority is even semantically broken wrt hierarchical > behavior. > > But really, make sure you look into the existing feature set that memcg > v2 provides already and come back if you find it unsuitable and we can > move from there. Soft limit reclaim is dead and we should let it RIP. Can't agree more here. Cgroup v2 memory protection mechanisms (memory.low/min) should perfectly solve the described problem. If not, let's fix them rather than extend soft reclaim which is already dead. Thanks!
