linux-kernel - 回复: [External Mail]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: <2a7b7fc3a48d4bb9a6394e51af074017@xiaomi.com>
Date: Fri, 4 Oct 2024 12:23:30 +0000
From: 高翔 <gaoxiang17@...omi.com>
To: Frank van der Linden <fvdl@...gle.com>, David Hildenbrand
	<david@...hat.com>
CC: Xiang Gao <gxxa03070307@...il.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: 回复: [External Mail]Re: [PATCH v2] mm/cma: print total and used count in cma_alloc()

-----邮件原件-----
发件人: Frank van der Linden <fvdl@...gle.com> 
发送时间: 2024年10月3日 3:50
收件人: David Hildenbrand <david@...hat.com>
抄送: Xiang Gao <gxxa03070307@...il.com>; akpm@...ux-foundation.org; linux-mm@...ck.org; linux-kernel@...r.kernel.org; 高翔 <gaoxiang17@...omi.com>
主题: [External Mail]Re: [PATCH v2] mm/cma: print total and used count in cma_alloc()

[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给misec@...omi.com进行反馈

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

Yes, I think it's simpler to add new members to the cma structure to manage. 
This does not add much overhead to the used count per print.

If this is possible, we can also add "caller" members to troubleshoot problems.