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.
