From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752228AbcL2CMc (ORCPT ); Wed, 28 Dec 2016 21:12:32 -0500 Received: from mailout2.samsung.com ([203.254.224.25]:49921 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752163AbcL2CMa (ORCPT ); Wed, 28 Dec 2016 21:12:30 -0500 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: b6c32a2c-f79ad6d000007a0b-9e-5864710c8f70 Content-transfer-encoding: 8BIT Subject: Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size To: Michal Nazarewicz , Michal Hocko Cc: gregkh@linuxfoundation.org, akpm@linux-foundation.org, labbott@redhat.com, m.szyprowski@samsung.com, gregory.0xf0@gmail.com, laurent.pinchart@ideasonboard.com, akinobu.mita@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jaewon31.kim@gmail.com From: Jaewon Kim Message-id: <58647136.8050403@samsung.com> Date: Thu, 29 Dec 2016 11:13:10 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 In-reply-to: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOJsWRmVeSWpSXmKPExsWy7bCmli5PYUqEwclbHBavDnQwWsxZv4bN onnxejaLadM3sFp0b57JaLFyzw8mi86JS9gtLu+aw2Zxb81/Vou1R+6yW7z+tozZYsHxFlYH Ho+ds+6ye8zumMnqsWlVJ5vHpk+T2D1OzPjN4rF/7hp2j3V/XjF5vN93lc2jb8sqRo/Pm+QC uKJSbTJSE1NSixRS85LzUzLz0m2VvIPjneNNzQwMdQ0tLcyVFPISc1NtlVx8AnTdMnOADldS KEvMKQUKBSQWFyvp29kU5ZeWpCpk5BeX2CpFGxoa6RkamOsZGRnpmZjHWhmZApUkpGY03xAr 2K1aceT/GZYGxrvSXYycHBICJhKbNu1jg7DFJC7cWw9kc3EICSxllGhq280OkhASaGeS+HxK BKbh7PkORoiiOYwSnx6uYAVJ8AoISvyYfI+li5GDg1lAXuLIpWyQMLOApsSLL5NYIOrvM0qc 3N0Itk1YIFDizcL1TCC2iIC3xINtK8GKmAW6mCSOrnoJlmAT0JZ4v2AS1AItiR1717KBLGAR UJW4/DsSJCwqECGxY+5HRhCbE6hkY3sr2HESAh/ZJe58nskOUi8hICux6QAzhOki8Wd5McQv whKvjm9hh7ClJf4uvQXV2s8osWlhAzOE08Mo0TG/nRmiyliit+cCM8RnfBK9v58wQQzlleho E4Io8ZDY9G49C4TtKPHh/x5miOdbmCT2fnrGPoFRfhZSeM1ChNcspPBawMi8ilEstaA4Nz21 2LTAUK84Mbe4NC9dLzk/dxMjONFq6exgvLfA+xCjAAejEg/vC5uUCCHWxLLiytxDjBIczEoi vF75QCHelMTKqtSi/Pii0pzU4kOMpsDQm8gsJZqcD8wCeSXxhibmFubmZubmloZmRkrivAsq rCOEBNITS1KzU1MLUotg+pg4OKUaGOf48H+dosowOdvHyNrg73rJjs6s2uebTvK080ztLG6u 2pepNKssYOrDeXeefN7MJ+ppy3nDcDnH5zcOavVuEctmdM+LuGr58Nu/t8aBe6ITQidPtAwP qDBYfd4hNoXdYq7n20zPCZPTFE6nH195LTm8WfHxStPPmiwKnTseVnsU/52l/W3xcyWW4oxE Qy3mouJEABMi5fbKAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsVy+t9jQV3uwpQIg9lXWC1eHehgtJizfg2b RfPi9WwW06ZvYLXo3jyT0WLlnh9MFp0Tl7BbXN41h83i3pr/rBZrj9xlt3j9bRmzxYLjLawO PB47Z91l95jdMZPVY9OqTjaPTZ8msXucmPGbxWP/3DXsHuv+vGLyeL/vKptH35ZVjB6fN8kF cEW52WSkJqakFimk5iXnp2TmpdsqhYa46VooKeQl5qbaKkXo+oYEKSmUJeaUAnlGBmjAwTnA PVhJ3y7BLaP5hljBbtWKI//PsDQw3pXuYuTkkBAwkTh7voMRwhaTuHBvPVsXIxeHkMAsRokF x9rAErwCghI/Jt9j6WLk4GAWkJc4cikbwlSXmDIlF6RCSOAho8Tp9ekgtrCAv0TP2y3MILaI gLfEg20rWSBGtjFJPFvRAuYwC3QxSSxsaWYCqWIT0JZ4v2ASK8QuLYkde9eygSxgEVCVuPw7 EiQsKhAhsXrdNbChnEAlG9tbGScwAh2JcN0shOtmIVy3gJF5FaNEakFyQXFSeq5RXmq5XnFi bnFpXrpecn7uJkZw/D6T3sF4eJf7IUYBDkYlHt4TCikRQqyJZcWVuYcYJTiYlUR4vfKBQrwp iZVVqUX58UWlOanFhxhNgS6cyCwlmpwPTC15JfGGJuYm5sYGFuaWliZGSuK8jbOfhQsJpCeW pGanphakFsH0MXFwSjUwtj8sWNn6/sOari0JPCW64RnHmqZcm3I1V5dNSr/spMJeltXrzI4/ OxLSrtqQezB60q6Yo4fdG22kUmyqVor+VAn+ME1z8jZ5qcdR5q9q6hLnTOXla/rl5LRK5toO g5tdp9mt1l8+tFjf5tAmYfNj5UKn+SdwcJrNUAs7vsH24QnTJeX7l5wLUWIpzkg01GIuKk4E ALpolaf1AgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20161229021227epcas5p3ddacf0938cf22b94731ef21e7987f989 X-Msg-Generator: CA X-Sender-IP: 203.254.230.27 X-Local-Sender: =?UTF-8?B?6rmA7J6s7JuQG1N5c3RlbSBTL1fqsJzrsJwy6re466O5KA==?= =?UTF-8?B?66y07ISgKRvsgrzshLHsoITsnpAbUzUo7LGF7J6EKS/ssYXsnoQ=?= X-Global-Sender: =?UTF-8?B?SmFld29uIEtpbRtTeXN0ZW0gUy9XIFImRCBHcm91cCAyG1Nh?= =?UTF-8?B?bXN1bmcgRWxlY3Ryb25pY3MbUzUvU2VuaW9yIEVuZ2luZWVy?= X-Sender-Code: =?UTF-8?B?QzEwG1RFTEUbQzEwRDkxMjI=?= CMS-TYPE: 105P DLP-Filter: Pass X-CFilter-Loop: Reflected X-HopCount: 7 X-CMS-RootMailID: 20161226041809epcas5p1981244de55764c10f1a80d80346f3664 X-RootMTR: 20161226041809epcas5p1981244de55764c10f1a80d80346f3664 References: <1482725891-10866-1-git-send-email-jaewon31.kim@samsung.com> <20161227100535.GB7662@dhcp22.suse.cz> <58634274.5060205@samsung.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Mical Hocko and Michal Nazarewicz Thank you for your comment. I agree with you on that the new bitmap API may not be used widely yet. Let me give up the bitmap API and resend another patch regarding CMA allocation failure. Thank you. On 2016년 12월 28일 23:14, Michal Nazarewicz wrote: > On Wed, Dec 28 2016, Jaewon Kim wrote: >> I did not add caller in this patch. >> I am using the patch in cma_alloc function like below to show >> available page status. >> >> + printk("number of available pages: "); >> + start = 0; >> + for (;;) { >> + bitmap_no = bitmap_find_next_zero_area_and_size(cma->bitmap, >> + cma->count, start, &nr); >> + if (bitmap_no >= cma->count) >> + break; >> + if (nr_total == 0) >> + printk("%u", nr); >> + else >> + printk("+%u", nr); >> + nr_total += nr; >> + start = bitmap_no + nr; >> + } >> + printk("=>%u pages, total: %lu pages\n", nr_total, cma->count); > I would be happier should you find other existing places where this > function can be used. With just one caller, I’m not convinced it is > worth it. > >>>> Signed-off-by: Jaewon Kim > The code itself is good, so > > Acked-by: Michal Nazarewicz > > and I’ll leave deciding whether it improves the kernel overall to > maintainers. ;) > >>>> --- >>>> include/linux/bitmap.h | 6 ++++++ >>>> lib/bitmap.c | 25 +++++++++++++++++++++++++ >>>> 2 files changed, 31 insertions(+) >>>> >>>> diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h >>>> index 3b77588..b724a6c 100644 >>>> --- a/include/linux/bitmap.h >>>> +++ b/include/linux/bitmap.h >>>> @@ -46,6 +46,7 @@ >>>> * bitmap_clear(dst, pos, nbits) Clear specified bit area >>>> * bitmap_find_next_zero_area(buf, len, pos, n, mask) Find bit free area >>>> * bitmap_find_next_zero_area_off(buf, len, pos, n, mask) as above >>>> + * bitmap_find_next_zero_area_and_size(buf, len, pos, n, mask) Find bit free area and its size >>>> * bitmap_shift_right(dst, src, n, nbits) *dst = *src >> n >>>> * bitmap_shift_left(dst, src, n, nbits) *dst = *src << n >>>> * bitmap_remap(dst, src, old, new, nbits) *dst = map(old, new)(src) >>>> @@ -123,6 +124,11 @@ extern unsigned long bitmap_find_next_zero_area_off(unsigned long *map, >>>> unsigned long align_mask, >>>> unsigned long align_offset); >>>> >>>> +extern unsigned long bitmap_find_next_zero_area_and_size(unsigned long *map, >>>> + unsigned long size, >>>> + unsigned long start, >>>> + unsigned int *nr); >>>> + >>>> /** >>>> * bitmap_find_next_zero_area - find a contiguous aligned zero area >>>> * @map: The address to base the search on >>>> diff --git a/lib/bitmap.c b/lib/bitmap.c >>>> index 0b66f0e..d02817c 100644 >>>> --- a/lib/bitmap.c >>>> +++ b/lib/bitmap.c >>>> @@ -332,6 +332,31 @@ unsigned long bitmap_find_next_zero_area_off(unsigned long *map, >>>> } >>>> EXPORT_SYMBOL(bitmap_find_next_zero_area_off); >>>> >>>> +/** >>>> + * bitmap_find_next_zero_area_and_size - find a contiguous aligned zero area >>>> + * @map: The address to base the search on >>>> + * @size: The bitmap size in bits >>>> + * @start: The bitnumber to start searching at >>>> + * @nr: The number of zeroed bits we've found >>>> + */ >>>> +unsigned long bitmap_find_next_zero_area_and_size(unsigned long *map, >>>> + unsigned long size, >>>> + unsigned long start, >>>> + unsigned int *nr) >>>> +{ >>>> + unsigned long index, i; >>>> + >>>> + *nr = 0; >>>> + index = find_next_zero_bit(map, size, start); >>>> + >>>> + if (index >= size) >>>> + return index; > I would remove this check. find_next_bit handles situation when index > == size and without this early return, *nr is always set. > >>>> + i = find_next_bit(map, size, index); >>>> + *nr = i - index; >>>> + return index; >>>> +} >>>> +EXPORT_SYMBOL(bitmap_find_next_zero_area_and_size); >>>> + >>>> /* >>>> * Bitmap printing & parsing functions: first version by Nadia Yvette Chambers, >>>> * second version by Paul Jackson, third by Joe Korty. >>>> -- >>>> 1.9.1 >>>> >>>> -- >>>> 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f200.google.com (mail-pf0-f200.google.com [209.85.192.200]) by kanga.kvack.org (Postfix) with ESMTP id 187F86B0069 for ; Wed, 28 Dec 2016 21:12:31 -0500 (EST) Received: by mail-pf0-f200.google.com with SMTP id y68so574170529pfb.6 for ; Wed, 28 Dec 2016 18:12:31 -0800 (PST) Received: from mailout2.samsung.com (mailout2.samsung.com. [203.254.224.25]) by mx.google.com with ESMTPS id u85si23799763pgb.137.2016.12.28.18.12.29 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 28 Dec 2016 18:12:30 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from epcas1p4.samsung.com (unknown [182.195.41.48]) by mailout2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0OIX01XF9CSSPM30@mailout2.samsung.com> for linux-mm@kvack.org; Thu, 29 Dec 2016 11:12:28 +0900 (KST) Content-transfer-encoding: 8BIT Subject: Re: [PATCH] lib: bitmap: introduce bitmap_find_next_zero_area_and_size From: Jaewon Kim Message-id: <58647136.8050403@samsung.com> Date: Thu, 29 Dec 2016 11:13:10 +0900 In-reply-to: References: <1482725891-10866-1-git-send-email-jaewon31.kim@samsung.com> <20161227100535.GB7662@dhcp22.suse.cz> <58634274.5060205@samsung.com> Sender: owner-linux-mm@kvack.org List-ID: To: Michal Nazarewicz , Michal Hocko Cc: gregkh@linuxfoundation.org, akpm@linux-foundation.org, labbott@redhat.com, m.szyprowski@samsung.com, gregory.0xf0@gmail.com, laurent.pinchart@ideasonboard.com, akinobu.mita@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jaewon31.kim@gmail.com Hello Mical Hocko and Michal Nazarewicz Thank you for your comment. I agree with you on that the new bitmap API may not be used widely yet. Let me give up the bitmap API and resend another patch regarding CMA allocation failure. Thank you. On 2016e?? 12i?? 28i? 1/4 23:14, Michal Nazarewicz wrote: > On Wed, Dec 28 2016, Jaewon Kim wrote: >> I did not add caller in this patch. >> I am using the patch in cma_alloc function like below to show >> available page status. >> >> + printk("number of available pages: "); >> + start = 0; >> + for (;;) { >> + bitmap_no = bitmap_find_next_zero_area_and_size(cma->bitmap, >> + cma->count, start, &nr); >> + if (bitmap_no >= cma->count) >> + break; >> + if (nr_total == 0) >> + printk("%u", nr); >> + else >> + printk("+%u", nr); >> + nr_total += nr; >> + start = bitmap_no + nr; >> + } >> + printk("=>%u pages, total: %lu pages\n", nr_total, cma->count); > I would be happier should you find other existing places where this > function can be used. With just one caller, Ia??m not convinced it is > worth it. > >>>> Signed-off-by: Jaewon Kim > The code itself is good, so > > Acked-by: Michal Nazarewicz > > and Ia??ll leave deciding whether it improves the kernel overall to > maintainers. ;) > >>>> --- >>>> include/linux/bitmap.h | 6 ++++++ >>>> lib/bitmap.c | 25 +++++++++++++++++++++++++ >>>> 2 files changed, 31 insertions(+) >>>> >>>> diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h >>>> index 3b77588..b724a6c 100644 >>>> --- a/include/linux/bitmap.h >>>> +++ b/include/linux/bitmap.h >>>> @@ -46,6 +46,7 @@ >>>> * bitmap_clear(dst, pos, nbits) Clear specified bit area >>>> * bitmap_find_next_zero_area(buf, len, pos, n, mask) Find bit free area >>>> * bitmap_find_next_zero_area_off(buf, len, pos, n, mask) as above >>>> + * bitmap_find_next_zero_area_and_size(buf, len, pos, n, mask) Find bit free area and its size >>>> * bitmap_shift_right(dst, src, n, nbits) *dst = *src >> n >>>> * bitmap_shift_left(dst, src, n, nbits) *dst = *src << n >>>> * bitmap_remap(dst, src, old, new, nbits) *dst = map(old, new)(src) >>>> @@ -123,6 +124,11 @@ extern unsigned long bitmap_find_next_zero_area_off(unsigned long *map, >>>> unsigned long align_mask, >>>> unsigned long align_offset); >>>> >>>> +extern unsigned long bitmap_find_next_zero_area_and_size(unsigned long *map, >>>> + unsigned long size, >>>> + unsigned long start, >>>> + unsigned int *nr); >>>> + >>>> /** >>>> * bitmap_find_next_zero_area - find a contiguous aligned zero area >>>> * @map: The address to base the search on >>>> diff --git a/lib/bitmap.c b/lib/bitmap.c >>>> index 0b66f0e..d02817c 100644 >>>> --- a/lib/bitmap.c >>>> +++ b/lib/bitmap.c >>>> @@ -332,6 +332,31 @@ unsigned long bitmap_find_next_zero_area_off(unsigned long *map, >>>> } >>>> EXPORT_SYMBOL(bitmap_find_next_zero_area_off); >>>> >>>> +/** >>>> + * bitmap_find_next_zero_area_and_size - find a contiguous aligned zero area >>>> + * @map: The address to base the search on >>>> + * @size: The bitmap size in bits >>>> + * @start: The bitnumber to start searching at >>>> + * @nr: The number of zeroed bits we've found >>>> + */ >>>> +unsigned long bitmap_find_next_zero_area_and_size(unsigned long *map, >>>> + unsigned long size, >>>> + unsigned long start, >>>> + unsigned int *nr) >>>> +{ >>>> + unsigned long index, i; >>>> + >>>> + *nr = 0; >>>> + index = find_next_zero_bit(map, size, start); >>>> + >>>> + if (index >= size) >>>> + return index; > I would remove this check. find_next_bit handles situation when index > == size and without this early return, *nr is always set. > >>>> + i = find_next_bit(map, size, index); >>>> + *nr = i - index; >>>> + return index; >>>> +} >>>> +EXPORT_SYMBOL(bitmap_find_next_zero_area_and_size); >>>> + >>>> /* >>>> * Bitmap printing & parsing functions: first version by Nadia Yvette Chambers, >>>> * second version by Paul Jackson, third by Joe Korty. >>>> -- >>>> 1.9.1 >>>> >>>> -- >>>> 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: email@kvack.org -- 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: email@kvack.org