回复: [External Mail]Re: [PATCH v2] mm/cma: print total and used count in cma_alloc()
From: 高翔
Date: Fri Oct 04 2024 - 08:23:49 EST
-----邮件原件-----
发件人: Frank van der Linden <fvdl@xxxxxxxxxx>
发送时间: 2024年10月3日 3:50
收件人: David Hildenbrand <david@xxxxxxxxxx>
抄送: Xiang Gao <gxxa03070307@xxxxxxxxx>; akpm@xxxxxxxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; 高翔 <gaoxiang17@xxxxxxxxxx>
主题: [External Mail]Re: [PATCH v2] mm/cma: print total and used count in cma_alloc()
[外部邮件] 此邮件来源于小米公司外部,请谨慎处理。若对邮件安全性存疑,请将邮件转发给misec@xxxxxxxxxx进行反馈
On Mon, Sep 30, 2024 at 2:34 AM David Hildenbrand <david@xxxxxxxxxx> wrote:
>
> On 29.09.24 05:27, Xiang Gao wrote:
> > From: gaoxiang17 <gaoxiang17@xxxxxxxxxx>
> >
>
> 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@xxxxxxxxxx>
> > ---
> > 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@xxxxxxxxxxxxxxxxxxxx/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.