Re: [LSF/MM/BPF TOPIC] Reducing zombie memcgs

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

 



On Tue, May 16, 2023 at 10:21:10PM +1000, Alistair Popple wrote:
> 
> Jason Gunthorpe <jgg@xxxxxxxxxx> writes:
> 
> > On Fri, May 12, 2023 at 06:45:13PM +1000, Alistair Popple wrote:
> >
> >> However review comments suggested it needed to be added as part of
> >> memcg. As soon as we do that we have to address how we deal with shared
> >> memory. If we stick with the original RLIMIT proposal this discussion
> >> goes away, but based on feedback I think I need to at least investigate
> >> integrating it into memcg to get anything merged.
> >
> > Personally I don't see how we can effectively solve the per-page
> > problem without also tracking all the owning memcgs for every
> > page. This means giving each struct page an array of memcgs
> >
> > I suspect this will be too expensive to be realistically
> > implementable.
> 
> Yep, agree with that. Tracking the list of memcgs was the main problem
> that prevented this.
> 
> > If it is done then we may not even need a pin controller on its own as
> > the main memcg should capture most of it. (althought it doesn't
> > distinguish between movable/swappable and non-swappable memory)
> >
> > But this is all being done for the libvirt people, so it would be good
> > to involve them
> 
> Do you know of anyone specifically there that is interested in this?
> I've rebased my series on latest upstream and am about to resend it so
> would be good to get some feedback from them.

"Daniel P. Berrange" <berrange@xxxxxxxxxx>
Alex Williamson <alex.williamson@xxxxxxxxxx>,

Are my usual gotos

Thanks,
Jason



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux