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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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.



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux