All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	hyesoo.yu@samsung.com, david@redhat.com, surenb@google.com,
	pullip.cho@samsung.com, joaodias@google.com, hridya@google.com,
	john.stultz@linaro.org, sumit.semwal@linaro.org,
	linux-media@vger.kernel.org, devicetree@vger.kernel.org,
	hch@infradead.org, robh+dt@kernel.org,
	linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH v4 1/4] mm: cma: introduce gfp flag in cma_alloc instead of no_warn
Date: Tue, 26 Jan 2021 11:12:14 -0800	[thread overview]
Message-ID: <YBBpjvBRtvi3Rl9F@google.com> (raw)
In-Reply-To: <20210126073808.GZ827@dhcp22.suse.cz>

On Tue, Jan 26, 2021 at 08:38:08AM +0100, Michal Hocko wrote:
> On Mon 25-01-21 11:42:34, Minchan Kim wrote:
> > On Mon, Jan 25, 2021 at 02:07:01PM +0100, Michal Hocko wrote:
> > > On Thu 21-01-21 09:54:59, Minchan Kim wrote:
> > > > The upcoming patch will introduce __GFP_NORETRY semantic
> > > > in alloc_contig_range which is a failfast mode of the API.
> > > > Instead of adding a additional parameter for gfp, replace
> > > > no_warn with gfp flag.
> > > > 
> > > > To keep old behaviors, it follows the rule below.
> > > > 
> > > >   no_warn 			gfp_flags
> > > > 
> > > >   false         		GFP_KERNEL
> > > >   true          		GFP_KERNEL|__GFP_NOWARN
> > > >   gfp & __GFP_NOWARN		GFP_KERNEL | (gfp & __GFP_NOWARN)
> > > > 
> > > > Reviewed-by: Suren Baghdasaryan <surenb@google.com>
> > > > Signed-off-by: Minchan Kim <minchan@kernel.org>
> > > [...]
> > > > diff --git a/mm/cma.c b/mm/cma.c
> > > > index 0ba69cd16aeb..d50627686fec 100644
> > > > --- a/mm/cma.c
> > > > +++ b/mm/cma.c
> > > > @@ -419,13 +419,13 @@ static inline void cma_debug_show_areas(struct cma *cma) { }
> > > >   * @cma:   Contiguous memory region for which the allocation is performed.
> > > >   * @count: Requested number of pages.
> > > >   * @align: Requested alignment of pages (in PAGE_SIZE order).
> > > > - * @no_warn: Avoid printing message about failed allocation
> > > > + * @gfp_mask: GFP mask to use during the cma allocation.
> > > 
> > > Call out supported gfp flags explicitly. Have a look at kvmalloc_node
> > > for a guidance.
> > 
> > How about this?
> > 
> > 
> > diff --git a/mm/cma.c b/mm/cma.c
> > index d50627686fec..b94727b694d6 100644
> > --- a/mm/cma.c
> > +++ b/mm/cma.c
> > @@ -423,6 +423,10 @@ static inline void cma_debug_show_areas(struct cma *cma) { }
> >   *
> >   * This function allocates part of contiguous memory on specific
> >   * contiguous memory area.
> > + *
> > + * For gfp_mask, GFP_KERNEL and __GFP_NORETRY are supported. __GFP_NORETRY
> > + * will avoid costly functions(e.g., waiting on page_writeback and locking)
> > + * at current implementaion during the page migration.
> 
> rather than explicitly mentioning what the flag implies I think it would
> be more useful to state the intended usecase. See how kvmalloc_node says
> "__GFP_RETRY_MAYFAIL is supported, and it should be used only if kmalloc is
> preferable to the vmalloc fallback, due to visible performance
> drawbacks.
> __GFP_NOWARN is also supported to suppress allocation failure messages."
> 
> This would help people not familiar with internals to see whether this
> flag is a good fit for them.
> 
> In this case I woul go with
> "
> @flags: gfp mask. Must be compatible (superset) with GFP_KERNEL.
> [...]
> Reclaim modifiers (__GFP_RETRY_MAYFAIL, __GFP_NOFAIL) are not supported.
> __GFP_NORETRY is supported, and it should be used for opportunistic
> allocation attempts that should rather fail quickly when the caller has
> a fallback strategy.
> "
> 
> Obviously for this patch you will go with a simple statement that
> Reclaim modifiers are not supported at all.

After more discussion for gfp_flags in thread of next patch, let me
changes a bit more based on it.

Thanks for the suggestion, Michal.

  reply	other threads:[~2021-01-27 10:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21 17:54 [PATCH v4 0/4] Chunk Heap Support on DMA-HEAP Minchan Kim
2021-01-21 17:54 ` [PATCH v4 1/4] mm: cma: introduce gfp flag in cma_alloc instead of no_warn Minchan Kim
2021-01-21 18:46   ` David Hildenbrand
2021-01-21 18:50   ` Minchan Kim
2021-01-25 13:07   ` Michal Hocko
2021-01-25 19:42     ` Minchan Kim
2021-01-26  7:38       ` Michal Hocko
2021-01-26 19:12         ` Minchan Kim [this message]
2021-01-27 20:21           ` Minchan Kim
2021-01-21 17:55 ` [PATCH v4 2/4] mm: failfast mode with __GFP_NORETRY in alloc_contig_range Minchan Kim
2021-01-25 13:12   ` Michal Hocko
2021-01-25 13:13     ` Michal Hocko
2021-01-25 19:33     ` Minchan Kim
2021-01-26  7:44       ` Michal Hocko
2021-01-26 19:10         ` Minchan Kim
2021-01-27  8:14           ` Michal Hocko
2021-01-27 20:42         ` Minchan Kim
2021-01-28  7:53           ` Michal Hocko
2021-01-28 16:56             ` Minchan Kim
2021-01-21 17:55 ` [PATCH v4 3/4] dt-bindings: reserved-memory: Make DMA-BUF CMA heap DT-configurable Minchan Kim
2021-01-26  7:07   ` John Stultz
2021-01-27 20:25     ` Hridya Valsaraju
2021-02-05 22:55   ` Rob Herring
2021-01-21 17:55 ` [PATCH v4 4/4] dma-buf: heaps: add chunk heap to dmabuf heaps Minchan Kim
2021-01-26  7:07   ` Christoph Hellwig
2021-01-26 19:27     ` Minchan Kim
2021-01-26  7:32   ` John Stultz
2021-01-26 19:24     ` Minchan Kim
2021-01-26  7:46   ` Michal Hocko
2021-01-26 19:25     ` Minchan Kim
2021-01-27  8:09       ` Michal Hocko

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=YBBpjvBRtvi3Rl9F@google.com \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hch@infradead.org \
    --cc=hridya@google.com \
    --cc=hyesoo.yu@samsung.com \
    --cc=joaodias@google.com \
    --cc=john.stultz@linaro.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=pullip.cho@samsung.com \
    --cc=robh+dt@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=surenb@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.