Re: [PATCH] mm: memcg: remove direct use of __memcg_kmem_uncharge_page

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

 



On Wed, Dec 13, 2023 at 7:01 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> On Wed, Dec 13, 2023 at 01:04:14PM +0000, Yosry Ahmed wrote:
> > memcg_kmem_uncharge_page() is an inline wrapper around
> > __memcg_kmem_uncharge_page() that checks memcg_kmem_online() before
> > making the function call. Internally, __memcg_kmem_uncharge_page() has a
> > folio_memcg_kmem() check.
> >
> > The only direct user of __memcg_kmem_uncharge_page(),
> > free_pages_prepare(), checks PageMemcgKmem() before calling it to avoid
> > the function call if possible. Move the folio_memcg_kmem() check from
> > __memcg_kmem_uncharge_page() to memcg_kmem_uncharge_page() as
> > PageMemcgKmem() -- which does the same thing under the hood. Now
> > free_pages_prepare() can also use memcg_kmem_uncharge_page().
>
> I think you've just pessimised all the other places which call
> memcg_kmem_uncharge_page().  It's a matter of probabilities.  In
> free_pages_prepare(), most of the pages being freed are not accounted
> to memcg.  Whereas in fork() we are absolutely certain that the pages
> were accounted because we accounted them.

The check was already there for other callers, but it was inside
__memcg_kmem_uncharge_page(). IIUC, the only change for other callers
is an extra call to compound_head(), and they are not hot paths AFAICT
so it shouldn't be noticeable.

Am I missing something? Perhaps your point is about how branch
prediction works across function call boundaries? or is this not about
performance at all?

>
> I think this is a bad change.





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

  Powered by Linux