Re: [RFC PATCH bpf-next 00/10] bpf, mm: Recharge pages when reuse bpf map

Roman Gushchin
2022-07-02T15:34:04Z

On Sat, Jul 02, 2022 at 11:24:10PM +0800, Yafang Shao wrote:
> On Sat, Jul 2, 2022 at 12:23 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
> >
> > On Sun, Jun 26, 2022 at 02:25:51PM +0800, Yafang Shao wrote:
> > > > > htab->map.numa_node);
> > > > > And then we'd better introduce an improvement for memcg,
> > > > > + /*
> > > > > + * Should wakeup async memcg reclaim first,
> > > > > + * in case there will be no direct memcg reclaim for a long time.
> > > > > + * We can either introduce async memcg reclaim
> > > > > + * or modify kswapd to reclaim a specific memcg
> > > > > + */
> > > > > + if (gfp_mask & __GFP_KSWAPD_RECLAIM)
> > > > > + wake_up_async_memcg_reclaim();
> > > > > if (!gfpflags_allow_blocking(gfp_mask))
> > > > > goto nomem;
> > > >
> > > > Hm, I see. It might be an issue if there is no global memory pressure, right?
> > > > Let me think what I can do here too.
> > > >
> > >
> > > Right. It is not a good idea to expect a global memory reclaimer to do it.
> > > Thanks for following up with it again.
> >
> > After thinking a bit more, I'm not sure if it's actually a good idea:
> > there might be not much memory to reclaim except the memory consumed by the bpf
> > map itself, so waking kswapd might be useless (and just consume cpu and drain
> > batteries).
> >
>
> I'm not sure if it is a generic problem.
> For example, a latency-sensitive process running in a container
> doesn't set __GFP_DIRECT_RECLAIM, but there're page cache pages in
> this container. If there's no global memory pressure or no other kinds
> of memory allocation in this container, these page cache pages will
> not be reclaimed for a long time.
> Maybe we should also check the number of page cache pages in this
> container before waking up kswapd, but I'm not quite sure of it.

It's not a generic problem but it might be very specific.
Anyway, it doesn't really matter, we shouldn't exceed memory.max.