From: Jan Kara <jack@suse.cz>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
Anders Larsen <al@alarsen.net>, Alasdair Kergon <agk@redhat.com>,
dm-devel@redhat.com, linux-fsdevel@vger.kernel.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-media@vger.kernel.org, Mark Fasheh <mfasheh@suse.com>,
Joel Becker <jlbec@evilplan.org>,
ocfs2-devel@oss.oracle.com, Jan Kara <jack@suse.cz>,
linux-ext4@vger.kernel.org,
Andreas Dilger <adilger.kernel@dilger.ca>,
Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH 01/10] string: introduce memweight
Date: Wed, 23 May 2012 11:21:13 +0200 [thread overview]
Message-ID: <20120523092113.GG10452@quack.suse.cz> (raw)
In-Reply-To: <1337520203-29147-1-git-send-email-akinobu.mita@gmail.com>
On Sun 20-05-12 22:23:14, Akinobu Mita wrote:
> memweight() is the function that counts the total number of bits set
> in memory area. The memory area doesn't need to be aligned to
> long-word boundary unlike bitmap_weight().
Thanks for the patch. I have some comments below.
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Anders Larsen <al@alarsen.net>
> Cc: Alasdair Kergon <agk@redhat.com>
> Cc: dm-devel@redhat.com
> Cc: linux-fsdevel@vger.kernel.org
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: linux-media@vger.kernel.org
> Cc: Mark Fasheh <mfasheh@suse.com>
> Cc: Joel Becker <jlbec@evilplan.org>
> Cc: ocfs2-devel@oss.oracle.com
> Cc: Jan Kara <jack@suse.cz>
> Cc: linux-ext4@vger.kernel.org
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andreas Dilger <adilger.kernel@dilger.ca>
> Cc: "Theodore Ts'o" <tytso@mit.edu>
> ---
> include/linux/string.h | 3 +++
> lib/string.c | 37 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 40 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index e033564..ffe0442 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -145,4 +145,7 @@ static inline bool strstarts(const char *str, const char *prefix)
> return strncmp(str, prefix, strlen(prefix)) == 0;
> }
> #endif
> +
> +extern size_t memweight(const void *ptr, size_t bytes);
> +
> #endif /* _LINUX_STRING_H_ */
> diff --git a/lib/string.c b/lib/string.c
> index e5878de..c8b92a0 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -26,6 +26,7 @@
> #include <linux/export.h>
> #include <linux/bug.h>
> #include <linux/errno.h>
> +#include <linux/bitmap.h>
>
> #ifndef __HAVE_ARCH_STRNICMP
> /**
> @@ -824,3 +825,39 @@ void *memchr_inv(const void *start, int c, size_t bytes)
> return check_bytes8(start, value, bytes % 8);
> }
> EXPORT_SYMBOL(memchr_inv);
> +
> +/**
> + * memweight - count the total number of bits set in memory area
> + * @ptr: pointer to the start of the area
> + * @bytes: the size of the area
> + */
> +size_t memweight(const void *ptr, size_t bytes)
> +{
> + size_t w = 0;
> + size_t longs;
> + union {
> + const void *ptr;
> + const unsigned char *b;
> + unsigned long address;
> + } bitmap;
Ugh, this is ugly and mostly unnecessary. Just use "const unsigned char
*bitmap".
> +
> + for (bitmap.ptr = ptr; bytes > 0 && bitmap.address % sizeof(long);
> + bytes--, bitmap.address++)
> + w += hweight8(*bitmap.b);
This can be:
count = ((unsigned long)bitmap) % sizeof(long);
while (count--) {
w += hweight(*bitmap);
bitmap++;
bytes--;
}
> +
> + for (longs = bytes / sizeof(long); longs > 0; ) {
> + size_t bits = min_t(size_t, INT_MAX & ~(BITS_PER_LONG - 1),
> + longs * BITS_PER_LONG);
I find it highly unlikely that someone would have such a large bitmap
(256 MB or more on 32-bit). Also the condition as you wrote it can just
overflow so it won't have the desired effect. Just do
BUG_ON(longs >= ULONG_MAX / BITS_PER_LONG);
and remove the loop completely. If someone comes with such a huge bitmap,
the code can be modified easily (after really closely inspecting whether
such a huge bitmap is really well justified).
> +
> + w += bitmap_weight(bitmap.ptr, bits);
> + bytes -= bits / BITS_PER_BYTE;
> + bitmap.address += bits / BITS_PER_BYTE;
> + longs -= bits / BITS_PER_LONG;
> + }
> +
> + for (; bytes > 0; bytes--, bitmap.address++)
> + w += hweight8(*bitmap.b);
> +
> + return w;
> +}
> +EXPORT_SYMBOL(memweight);
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2012-05-23 9:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-20 13:23 [PATCH 01/10] string: introduce memweight Akinobu Mita
2012-05-20 13:23 ` [PATCH 05/10] affs: use memweight() Akinobu Mita
2012-05-23 9:21 ` Jan Kara [this message]
2012-05-23 12:12 ` [PATCH 01/10] string: introduce memweight Akinobu Mita
2012-05-23 12:29 ` Jan Kara
2012-05-23 13:16 ` Matthew Wilcox
2012-05-24 11:54 ` Akinobu Mita
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=20120523092113.GG10452@quack.suse.cz \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=agk@redhat.com \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=al@alarsen.net \
--cc=dm-devel@redhat.com \
--cc=jlbec@evilplan.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mfasheh@suse.com \
--cc=ocfs2-devel@oss.oracle.com \
--cc=tytso@mit.edu \
/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).