From: Matthew Wilcox <willy@infradead.org>
To: Pintu Agarwal <pintu.ping@gmail.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
Pintu Kumar <quic_pintu@quicinc.com>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
linux-mm@kvack.org
Subject: Re: [PATCH v2] mm: cma: print cma name as well in cma_alloc debug
Date: Fri, 7 Jul 2023 15:09:58 +0100 [thread overview]
Message-ID: <ZKgctnmuVbLvYb9d@casper.infradead.org> (raw)
In-Reply-To: <CAOuPNLiOO_Pa=J_-0RhDBQ0auL0rgCjmpCZHtH3ngv6D1OhW6Q@mail.gmail.com>
On Fri, Jul 07, 2023 at 07:36:20PM +0530, Pintu Agarwal wrote:
> On Fri, 7 Jul 2023 at 18:16, Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Fri, Jul 07, 2023 at 03:57:42PM +0530, Anshuman Khandual wrote:
> > > LGTM, cma->name is an identifying attribute for the region for which the allocation
> > > request was made. But how about using cma_get_name() helper instead ? Very few call
> > > sites have been using the helper.
> >
> > It's not really a "helper", is it? The function name is longer than
> > its implementation.
> >
> > cma_get_name(cma)
> > vs
> > cma->name
> >
> > Plus there's the usual question about whether a "got" name needs to be
> > "put" (does it grab a refcount?)
> >
> > I think it's useful that this function exists since it lets us not expose
> > struct cma outside of mm/, but it really should be called cma_name()
> > and I don't think we should be encouraging its use within cma.c.
>
> Also, cma_get_name() is a trivial assignment.
> And in one of the previous patches we avoided function calls with
> trivial assignments.
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/kernel/dma/contiguous.c?h=next-20230705&id=5af638931eb374aa0894d8343cee72f50307ef20
> dma-contiguous: remove dev_set_cma_area
>
> One more question from here:
> pr_debug("%s(cma %p, name: %s, count %lu, align %d)\n", __func__,
> (void *)cma, cma->name, count, align);
>
> Do we really need this "cma %p" printing ?
> I hardly check it and simply rely on name and count.
Printing pointers is almost always a bad idea. Printing the base_pfn
might be a good idea to distinguish CMAs which happen to have the
same name?
next prev parent reply other threads:[~2023-07-07 14:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-06 18:27 [PATCH] mm: cma: print cma name as well in cma_alloc debug Pintu Kumar
2023-07-06 18:33 ` [PATCH v2] " Pintu Kumar
2023-07-07 10:27 ` Anshuman Khandual
2023-07-07 12:46 ` Matthew Wilcox
2023-07-07 14:06 ` Pintu Agarwal
2023-07-07 14:09 ` Matthew Wilcox [this message]
2023-07-07 14:16 ` Pintu Agarwal
2023-07-07 14:22 ` Matthew Wilcox
2023-07-07 14:33 ` Pintu Agarwal
2023-07-08 6:52 ` Pintu Agarwal
2023-07-12 14:02 ` Pintu Agarwal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZKgctnmuVbLvYb9d@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pintu.ping@gmail.com \
--cc=quic_pintu@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).