linux-kernel - Re: [PATCH v2] mm/cma: print total and used count in cma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPTztWY-CD9REdJq_-HeELJ+dX68+OZC76T0F+YMyZKMc-DHug@mail.gmail.com>
Date: Wed, 2 Oct 2024 12:50:08 -0700
From: Frank van der Linden <fvdl@...gle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Xiang Gao <gxxa03070307@...il.com>, akpm@...ux-foundation.org, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, gaoxiang17 <gaoxiang17@...omi.com>
Subject: Re: [PATCH v2] mm/cma: print total and used count in cma_alloc()

On Mon, Sep 30, 2024 at 2:34 AM David Hildenbrand <david@...hat.com> wrote:
>
> On 29.09.24 05:27, Xiang Gao wrote:
> > From: gaoxiang17 <gaoxiang17@...omi.com>
> >
>
> We should add here
>
> "To debug CMA allocations (especially failing ones), it is valuable to
> know the state of CMA: how many pages out of the total ones are
> allocated, and how many were requested to be allocated. Let's print
> some more information."
>
> I assume Andrew can fix that up when applying.
>
> > before:
> > [   24.407814] cma: cma_alloc(cma (____ptrval____), name: reserved, count 1, align 0)
> > [   24.413397] cma: cma_alloc(cma (____ptrval____), name: reserved, count 1, align 0)
> > [   24.415886] cma: cma_alloc(cma (____ptrval____), name: reserved, count 1, align 0)
> >
> > after:
> > [   24.069738] cma: cma_alloc(cma (____ptrval____), name: reserved, total pages: 16384, used pages: 64, request pages: 1, align 0)
> > [   24.075317] cma: cma_alloc(cma (____ptrval____), name: reserved, total pages: 16384, used pages: 65, request pages: 1, align 0)
> > [   24.078455] cma: cma_alloc(cma (____ptrval____), name: reserved, total pages: 16384, used pages: 66, request pages: 1, align 0)
> >
> > Signed-off-by: gaoxiang17 <gaoxiang17@...omi.com>
> > ---
> >   mm/cma.c | 15 +++++++++++++--
> >   1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/cma.c b/mm/cma.c
> > index 2d9fae939283..90b3fdbac19c 100644
> > --- a/mm/cma.c
> > +++ b/mm/cma.c
> > @@ -403,6 +403,17 @@ static void cma_debug_show_areas(struct cma *cma)
> >       spin_unlock_irq(&cma->lock);
> >   }
> >
> > +static unsigned long cma_get_used_pages(struct cma *cma)
> > +{
> > +     unsigned long used;
> > +
> > +     spin_lock_irq(&cma->lock);
> > +     used = bitmap_weight(cma->bitmap, (int)cma_bitmap_maxno(cma));
> > +     spin_unlock_irq(&cma->lock);
>
> This adds overhead to each allocation, even if debug outputs are ignored
> I assume?
>
> I wonder if we'd want to print these details only when our allocation
> failed?
>
> Alternatively, we could actually track how many pages are allocated in
> the cma, so we don't have to traverse the complete bitmap on every
> allocation.
>

Yep, that's what I did as part of
https://lore.kernel.org/all/20240724124845.614c03ad39f8af3729cebee6@linux-foundation.org/T/

That patch didn't make it in (yet). I'm happy for it to be combined
with this one if that's easier.

- Frank