Messages in this thread | | | Date | Mon, 25 Jan 2021 23:38:17 +0200 | From | Mike Rapoport <> | Subject | Re: [PATCH v16 08/11] secretmem: add memcg accounting |
| |
On Mon, Jan 25, 2021 at 05:54:51PM +0100, Michal Hocko wrote: > On Thu 21-01-21 14:27:20, Mike Rapoport wrote: > > From: Mike Rapoport <rppt@linux.ibm.com> > > > > Account memory consumed by secretmem to memcg. The accounting is updated > > when the memory is actually allocated and freed. > > What does this mean?
That means that the accounting is updated when secretmem does cma_alloc() and cma_relase().
> What are the lifetime rules?
Hmm, what do you mean by lifetime rules?
> [...] > > > +static int secretmem_account_pages(struct page *page, gfp_t gfp, int order) > > +{ > > + int err; > > + > > + err = memcg_kmem_charge_page(page, gfp, order); > > + if (err) > > + return err; > > + > > + /* > > + * seceremem caches are unreclaimable kernel allocations, so treat > > + * them as unreclaimable slab memory for VM statistics purposes > > + */ > > + mod_lruvec_page_state(page, NR_SLAB_UNRECLAIMABLE_B, > > + PAGE_SIZE << order); > > A lot of memcg accounted memory is not reclaimable. Why do you abuse > SLAB counter when this is not a slab owned memory? Why do you use the > kmem accounting API when __GFP_ACCOUNT should give you the same without > this details?
I cannot use __GFP_ACCOUNT because cma_alloc() does not use gfp. Besides, kmem accounting with __GFP_ACCOUNT does not seem to update stats and there was an explicit request for statistics:
https://lore.kernel.org/lkml/CALo0P13aq3GsONnZrksZNU9RtfhMsZXGWhK1n=xYJWQizCd4Zw@mail.gmail.com/
As for (ab)using NR_SLAB_UNRECLAIMABLE_B, as it was already discussed here:
https://lore.kernel.org/lkml/20201129172625.GD557259@kernel.org/
I think that a dedicated stats counter would be too much at the moment and NR_SLAB_UNRECLAIMABLE_B is the only explicit stat for unreclaimable memory.
-- Sincerely yours, Mike.
| |