From: Jaewon Kim <jaewon31.kim@samsung.com>
To: Michal Nazarewicz <mina86@mina86.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 17:06:29 +0900 [thread overview]
Message-ID: <586A0A05.4040708@samsung.com> (raw)
In-Reply-To: <xa1tmvfahscn.fsf@mina86.com>
On 2017e?? 01i?? 02i? 1/4 15:46, Michal Nazarewicz wrote:
> 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 a??cma_debug_show_areasa??. All other functions have a??cmaa?? as
> prefix so thata??s more consistent.
OK no problem.
>
>> +{
>> + 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;
>> }
>> --
>>
Added the latest.
next prev parent reply other threads:[~2017-01-02 8:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20161229022722epcas5p4be0e1924f3c8d906cbfb461cab8f0374@epcas5p4.samsung.com>
2016-12-29 2:28 ` Jaewon Kim
2016-12-29 9:14 ` Michal Hocko
2016-12-29 9:26 ` Jaewon Kim
2016-12-29 9:43 ` Michal Hocko
2016-12-30 6:27 ` Jaewon Kim
2016-12-29 14:20 ` Michal Nazarewicz
2016-12-30 7:24 ` Jaewon Kim
2016-12-30 9:44 ` Michal Hocko
2017-01-01 21:59 ` Michal Nazarewicz
2017-01-02 5:42 ` Jaewon Kim
2017-01-02 6:46 ` Michal Nazarewicz
2017-01-02 8:06 ` Jaewon Kim [this message]
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=586A0A05.4040708@samsung.com \
--to=jaewon31.kim@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=jaewon31.kim@gmail.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 \
--cc=mina86@mina86.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