[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20241004153947.43c5b16b7f75b0f60e918019@linux-foundation.org>
Date: Fri, 4 Oct 2024 15:39:47 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: 高翔 <gaoxiang17@...omi.com>
Cc: Frank van der Linden <fvdl@...gle.com>, David Hildenbrand
<david@...hat.com>, Xiang Gao <gxxa03070307@...il.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: Re: 回复: [External Mail]Re: [PATCH v2] mm/cma:
print total and used count in cma_alloc()
On Fri, 4 Oct 2024 12:23:30 +0000 高翔 <gaoxiang17@...omi.com> wrote:
> > > +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.
That patch has been forgotten about. As I asked in July,
"I suggest a resend, and add some Cc:s for likely reviewers."
Powered by blists - more mailing lists