All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Jaewon Kim <jaewon31.kim@samsung.com>, Michal Hocko <mhocko@kernel.org>
Cc: gregkh@linuxfoundation.org, akpm@linux-foundation.org,
	labbott@redhat.com, m.szyprowski@samsung.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, jaewon31.kim@gmail.com
Subject: Re: [PATCH] mm: cma: print allocation failure reason and bitmap status
Date: Mon, 02 Jan 2017 07:46:16 +0100	[thread overview]
Message-ID: <xa1tmvfahscn.fsf@mina86.com> (raw)
In-Reply-To: <5869E849.1040605@samsung.com>

On Mon, Jan 02 2017, Jaewon Kim wrote:
> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, EINTR.
> But we did not know error reason so far. This patch prints the error value.
>
> Additionally if CONFIG_CMA_DEBUG is enabled, this patch shows bitmap status to
> know available pages. Actually CMA internally tries on all available regions
> because some regions can be failed because of EBUSY. Bitmap status is useful to
> know in detail on both ENONEM and EBUSY;
>  ENOMEM: not tried at all because of no available region
>          it could be too small total region or could be fragmentation issue
>  EBUSY:  tried some region but all failed
>
> This is an ENOMEM example with this patch.
> [   12.415458]  [2:   Binder:714_1:  744] cma: cma_alloc: alloc failed, req-size: 256 pages, ret: -12
> If CONFIG_CMA_DEBUG is enabled, avabile pages also will be shown as concatenated
> size@position format. So 4@572 means that there are 4 available pages at 572
> position starting from 0 position.
> [   12.415503]  [2:   Binder:714_1:  744] cma: number of available pages: 4@572+7@585+7@601+8@632+38@730+166@1114+127@1921=> 357 free of 2048 total pages
>
> Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
> Acked-by: Michal Nazarewicz <mina86@mina86.com>
> ---
>  mm/cma.c | 34 +++++++++++++++++++++++++++++++++-
>  1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/mm/cma.c b/mm/cma.c
> index c960459..9e037541 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -353,6 +353,32 @@ int __init cma_declare_contiguous(phys_addr_t base,
>      return ret;
>  }
>  
> +#ifdef CONFIG_CMA_DEBUG
> +static void debug_show_cma_areas(struct cma *cma)

Make it ‘cma_debug_show_areas’.  All other functions have ‘cma’ as
prefix so that’s more consistent.

> +{
> +    unsigned long next_zero_bit, next_set_bit;
> +    unsigned long start = 0;
> +    unsigned int nr_zero, nr_total = 0;
> +
> +    mutex_lock(&cma->lock);
> +    pr_info("number of available pages: ");
> +    for (;;) {
> +        next_zero_bit = find_next_zero_bit(cma->bitmap, cma->count, start);
> +        if (next_zero_bit >= cma->count)
> +            break;
> +        next_set_bit = find_next_bit(cma->bitmap, cma->count, next_zero_bit);
> +        nr_zero = next_set_bit - next_zero_bit;
> +        pr_cont("%s%u@%lu", nr_total ? "+" : "", nr_zero, next_zero_bit);
> +        nr_total += nr_zero;
> +        start = next_zero_bit + nr_zero;
> +    }
> +    pr_cont("=> %u free of %lu total pages\n", nr_total, cma->count);
> +    mutex_unlock(&cma->lock);
> +}
> +#else
> +static inline void debug_show_cma_areas(struct cma *cma) { }
> +#endif
> +
>  /**
>   * cma_alloc() - allocate pages from contiguous area
>   * @cma:   Contiguous memory region for which the allocation is performed.
> @@ -369,7 +395,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
>      unsigned long start = 0;
>      unsigned long bitmap_maxno, bitmap_no, bitmap_count;
>      struct page *page = NULL;
> -    int ret;
> +    int ret = -ENOMEM;
>  
>      if (!cma || !cma->count)
>          return NULL;
> @@ -426,6 +452,12 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
>  
>      trace_cma_alloc(pfn, page, count, align);
>  
> +    if (ret) {
> +        pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
> +            __func__, count, ret);
> +        debug_show_cma_areas(cma);
> +    }
> +
>      pr_debug("%s(): returned %p\n", __func__, page);
>      return page;
>  }
> -- 
>

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Michal Nazarewicz <mina86@mina86.com>
To: Jaewon Kim <jaewon31.kim@samsung.com>, Michal Hocko <mhocko@kernel.org>
Cc: gregkh@linuxfoundation.org, akpm@linux-foundation.org,
	labbott@redhat.com, m.szyprowski@samsung.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, jaewon31.kim@gmail.com
Subject: Re: [PATCH] mm: cma: print allocation failure reason and bitmap status
Date: Mon, 02 Jan 2017 07:46:16 +0100	[thread overview]
Message-ID: <xa1tmvfahscn.fsf@mina86.com> (raw)
In-Reply-To: <5869E849.1040605@samsung.com>

On Mon, Jan 02 2017, Jaewon Kim wrote:
> There are many reasons of CMA allocation failure such as EBUSY, ENOMEM, EINTR.
> But we did not know error reason so far. This patch prints the error value.
>
> Additionally if CONFIG_CMA_DEBUG is enabled, this patch shows bitmap status to
> know available pages. Actually CMA internally tries on all available regions
> because some regions can be failed because of EBUSY. Bitmap status is useful to
> know in detail on both ENONEM and EBUSY;
>  ENOMEM: not tried at all because of no available region
>          it could be too small total region or could be fragmentation issue
>  EBUSY:  tried some region but all failed
>
> This is an ENOMEM example with this patch.
> [   12.415458]  [2:   Binder:714_1:  744] cma: cma_alloc: alloc failed, req-size: 256 pages, ret: -12
> If CONFIG_CMA_DEBUG is enabled, avabile pages also will be shown as concatenated
> size@position format. So 4@572 means that there are 4 available pages at 572
> position starting from 0 position.
> [   12.415503]  [2:   Binder:714_1:  744] cma: number of available pages: 4@572+7@585+7@601+8@632+38@730+166@1114+127@1921=> 357 free of 2048 total pages
>
> Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
> Acked-by: Michal Nazarewicz <mina86@mina86.com>
> ---
>  mm/cma.c | 34 +++++++++++++++++++++++++++++++++-
>  1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/mm/cma.c b/mm/cma.c
> index c960459..9e037541 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -353,6 +353,32 @@ int __init cma_declare_contiguous(phys_addr_t base,
>      return ret;
>  }
>  
> +#ifdef CONFIG_CMA_DEBUG
> +static void debug_show_cma_areas(struct cma *cma)

Make it ‘cma_debug_show_areas’.  All other functions have ‘cma’ as
prefix so that’s more consistent.

> +{
> +    unsigned long next_zero_bit, next_set_bit;
> +    unsigned long start = 0;
> +    unsigned int nr_zero, nr_total = 0;
> +
> +    mutex_lock(&cma->lock);
> +    pr_info("number of available pages: ");
> +    for (;;) {
> +        next_zero_bit = find_next_zero_bit(cma->bitmap, cma->count, start);
> +        if (next_zero_bit >= cma->count)
> +            break;
> +        next_set_bit = find_next_bit(cma->bitmap, cma->count, next_zero_bit);
> +        nr_zero = next_set_bit - next_zero_bit;
> +        pr_cont("%s%u@%lu", nr_total ? "+" : "", nr_zero, next_zero_bit);
> +        nr_total += nr_zero;
> +        start = next_zero_bit + nr_zero;
> +    }
> +    pr_cont("=> %u free of %lu total pages\n", nr_total, cma->count);
> +    mutex_unlock(&cma->lock);
> +}
> +#else
> +static inline void debug_show_cma_areas(struct cma *cma) { }
> +#endif
> +
>  /**
>   * cma_alloc() - allocate pages from contiguous area
>   * @cma:   Contiguous memory region for which the allocation is performed.
> @@ -369,7 +395,7 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
>      unsigned long start = 0;
>      unsigned long bitmap_maxno, bitmap_no, bitmap_count;
>      struct page *page = NULL;
> -    int ret;
> +    int ret = -ENOMEM;
>  
>      if (!cma || !cma->count)
>          return NULL;
> @@ -426,6 +452,12 @@ struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align)
>  
>      trace_cma_alloc(pfn, page, count, align);
>  
> +    if (ret) {
> +        pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
> +            __func__, count, ret);
> +        debug_show_cma_areas(cma);
> +    }
> +
>      pr_debug("%s(): returned %p\n", __func__, page);
>      return page;
>  }
> -- 
>

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

  reply	other threads:[~2017-01-02  6:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20161229022722epcas5p4be0e1924f3c8d906cbfb461cab8f0374@epcas5p4.samsung.com>
2016-12-29  2:28 ` [PATCH] mm: cma: print allocation failure reason and bitmap status Jaewon Kim
2016-12-29  2:28   ` Jaewon Kim
2016-12-29  9:14   ` Michal Hocko
2016-12-29  9:14     ` Michal Hocko
2016-12-29  9:26     ` Jaewon Kim
2016-12-29  9:26       ` Jaewon Kim
2016-12-29  9:43       ` Michal Hocko
2016-12-29  9:43         ` Michal Hocko
2016-12-30  6:27         ` Jaewon Kim
2016-12-30  6:27           ` Jaewon Kim
2016-12-29 14:20     ` Michal Nazarewicz
2016-12-29 14:20       ` Michal Nazarewicz
2016-12-30  7:24       ` Jaewon Kim
2016-12-30  7:24         ` Jaewon Kim
2016-12-30  9:44         ` Michal Hocko
2016-12-30  9:44           ` Michal Hocko
2017-01-01 21:59           ` Michal Nazarewicz
2017-01-01 21:59             ` Michal Nazarewicz
2017-01-02  5:42             ` Jaewon Kim
2017-01-02  5:42               ` Jaewon Kim
2017-01-02  6:46               ` Michal Nazarewicz [this message]
2017-01-02  6:46                 ` Michal Nazarewicz
2017-01-02  8:06                 ` Jaewon Kim
2017-01-02  8:06                   ` Jaewon Kim
2017-01-02  8:47             ` Michal Hocko
2017-01-02  8:47               ` 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=xa1tmvfahscn.fsf@mina86.com \
    --to=mina86@mina86.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jaewon31.kim@gmail.com \
    --cc=jaewon31.kim@samsung.com \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mhocko@kernel.org \
    /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.