On Tue 28-04-20 20:25:49, Yafang Shao wrote: > On Tue, Apr 28, 2020 at 6:43 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: [...] > > [...] > > > > So it would be really more helpful to not insist on unrelated > > > > implementation details and focus on two things 1) split up the effective > > > > values calculation from the predicate (cleanup without any functional > > > > changes) 2) make the calculation more robust against racing reclaimers. > > > > > > > > > > Another thing should be considered as well, 0) don't access > > > memroy.emin and elow in get_scan_count(). > > > > If you can achieve the gradual transition over protections by other > > means then I am really interested in more details. > > sc->protection I believe I have covered this one already. > I make my statement again - accessing the realy fragile emin & elow > in very deep reclaiming code is a totally horrible HACK, that is the > root of all evil. Both me and Johannes tried to explain that we simply have to calculate effective values for the whole reclaim tree. That has to be done somehow. Caching effective values is a tricky solution but I am not really aware of another without requiring to allocate storage for intermediate results. Maybe there is a way to make that storage really small to live on the stack or some other tricks. If you do not have any clever ideas how to achieve that then we have to live with the caching at the memcg level. And then we have to deal with 2) mentioned above. -- Michal Hocko SUSE Labs
