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

Yafang Shao
2022-07-02T15:24:51Z

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.

--
Regards
Yafang