Re: Possible mem cgroup bug in kernels between 4.18.0 and 5.3-rc1.

[Hillf Danton <hdanton@sina.com>]

On Fri, 2 Aug 2019 21:40:29 +0800 Michal Hocko wrote:
> 
> On Fri 02-08-19 20:10:58, Hillf Danton wrote:
> >
> > On Fri, 2 Aug 2019 16:18:40 +0800 Michal Hocko wrote:
> [...]
> > > Huh, what? You are effectively saying that we should fail the charge
> > > when the requested nr_pages would fit in. This doesn't make much sense
> > > to me. What are you trying to achive here?
> >
> > The report looks like the result of a tight loop.
> > I want to break it and make the end result of do_page_fault unsuccessful
> > if nr_retries rounds of page reclaiming fail to get work done. What made
> > me a bit over stretched is how to determine if the chargee is a memhog
> > in memcg's vocabulary.
> > What I prefer here is that do_page_fault succeeds, even if the chargee
> > exhausts its memory quota/budget granted, as long as more than nr_pages
> > can be reclaimed _within_ nr_retries rounds. IOW the deadline for memhog
> > is nr_retries, and no more.
> 
> No, this really doesn't really make sense because it leads to pre-mature
> charge failures. The charge path is funadamentally not different from
> the page allocator path. We do try to reclaim and retry the allocation.
> We keep retrying for ever for non-costly order requests in both cases
> (modulo some corner cases like oom victims etc.).

You are right. It is hard to produce a cure for all corner cases.
We can handle them one by one to reduce the chance that a cpuhog
comes under memory pressure.

Hillf