[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPTztWbTieT1St6QRR6dJAPyVrZHU4GVW8F2j43whMdf3+Vu1g@mail.gmail.com>
Date: Fri, 4 Oct 2024 15:55:57 -0700
From: Frank van der Linden <fvdl@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: 高翔 <gaoxiang17@...omi.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, Oct 4, 2024 at 3:39 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> 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."
Indeed - I certainly wasn't suggesting that anyone else forgot about
it, it's up to me to follow up here, and I haven't yet.
- Frank
Powered by blists - more mailing lists