From: "Sungjong Seo" <sj1557.seo@samsung.com>
To: "'John Sanpe'" <sanpeqf@gmail.com>, <linkinjeon@kernel.org>,
<willy@infradead.org>
Cc: <linux-fsdevel@vger.kernel.org>, <Andy.Wu@sony.com>,
<Wataru.Aoyama@sony.com>, <cpgs@samsung.com>
Subject: RE: [PATCH v3] exfat/balloc: using hweight instead of internal logic
Date: Thu, 7 Dec 2023 11:40:37 +0900 [thread overview]
Message-ID: <1461149300.81701918783708.JavaMail.epsvc@epcpadp4> (raw)
In-Reply-To: <20231205155837.1675052-1-sanpeqf@gmail.com>
> Replace the internal table lookup algorithm with the hweight
> library, which has instruction set acceleration capabilities.
>
> Use it to increase the length of a single calculation of
> the exfat_find_free_bitmap function to the long type.
>
> Signed-off-by: John Sanpe <sanpeqf@gmail.com>
Thanks for your patch.
Acked-by: Sungjong Seo <sj1557.seo@samsung.com>
> ---
> fs/exfat/balloc.c | 48 +++++++++++++++++++++--------------------------
> 1 file changed, 21 insertions(+), 27 deletions(-)
>
> diff --git a/fs/exfat/balloc.c b/fs/exfat/balloc.c
> index e918decb3735..69804a1b92d0 100644
> --- a/fs/exfat/balloc.c
> +++ b/fs/exfat/balloc.c
> @@ -5,11 +5,22 @@
>
> #include <linux/blkdev.h>
> #include <linux/slab.h>
> +#include <linux/bitmap.h>
> #include <linux/buffer_head.h>
>
> #include "exfat_raw.h"
> #include "exfat_fs.h"
>
> +#if BITS_PER_LONG == 32
> +# define __le_long __le32
> +# define lel_to_cpu(A) le32_to_cpu(A)
> +#elif BITS_PER_LONG == 64
> +# define __le_long __le64
> +# define lel_to_cpu(A) le64_to_cpu(A)
> +#else
> +# error "BITS_PER_LONG not 32 or 64"
> +#endif
> +
> static const unsigned char free_bit[] = {
> 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, 4, 0, 1, 0, 2,/* 0 ~
> 19*/
> 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, 5, 0, 1, 0, 2, 0, 1, 0, 3,/* 20 ~
> 39*/
> @@ -26,22 +37,6 @@ static const unsigned char free_bit[] = {
> 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0 /*240 ~
> 254*/
> };
>
> -static const unsigned char used_bit[] = {
> - 0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4, 1, 2, 2, 3,/* 0 ~
> 19*/
> - 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5, 1, 2, 2, 3, 2, 3, 3, 4,/* 20 ~
> 39*/
> - 2, 3, 3, 4, 3, 4, 4, 5, 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5,/* 40 ~
> 59*/
> - 4, 5, 5, 6, 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,/* 60 ~
> 79*/
> - 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 2, 3, 3, 4,/* 80 ~
> 99*/
> - 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 3, 4, 4, 5, 4, 5, 5, 6,/*100 ~
> 119*/
> - 4, 5, 5, 6, 5, 6, 6, 7, 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4,/*120 ~
> 139*/
> - 3, 4, 4, 5, 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,/*140 ~
> 159*/
> - 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 3, 4, 4, 5,/*160 ~
> 179*/
> - 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 2, 3, 3, 4, 3, 4, 4, 5,/*180 ~
> 199*/
> - 3, 4, 4, 5, 4, 5, 5, 6, 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6,/*200 ~
> 219*/
> - 5, 6, 6, 7, 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,/*220 ~
> 239*/
> - 4, 5, 5, 6, 5, 6, 6, 7, 5, 6, 6, 7, 6, 7, 7, 8 /*240 ~
> 255*/
> -};
> -
> /*
> * Allocation Bitmap Management Functions
> */
> @@ -244,25 +239,24 @@ int exfat_count_used_clusters(struct super_block
*sb,
> unsigned int *ret_count)
> unsigned int count = 0;
> unsigned int i, map_i = 0, map_b = 0;
> unsigned int total_clus = EXFAT_DATA_CLUSTER_COUNT(sbi);
> - unsigned int last_mask = total_clus & BITS_PER_BYTE_MASK;
> - unsigned char clu_bits;
> - const unsigned char last_bit_mask[] = {0, 0b00000001, 0b00000011,
> - 0b00000111, 0b00001111, 0b00011111, 0b00111111, 0b01111111};
> + unsigned int last_mask = total_clus & (BITS_PER_LONG - 1);
> + unsigned long *bitmap, clu_bits;
>
> total_clus &= ~last_mask;
> - for (i = 0; i < total_clus; i += BITS_PER_BYTE) {
> - clu_bits = *(sbi->vol_amap[map_i]->b_data + map_b);
> - count += used_bit[clu_bits];
> - if (++map_b >= (unsigned int)sb->s_blocksize) {
> + for (i = 0; i < total_clus; i += BITS_PER_LONG) {
> + bitmap = (void *)(sbi->vol_amap[map_i]->b_data + map_b);
> + count += hweight_long(*bitmap);
> + map_b += sizeof(long);
> + if (map_b >= (unsigned int)sb->s_blocksize) {
> map_i++;
> map_b = 0;
> }
> }
>
> if (last_mask) {
> - clu_bits = *(sbi->vol_amap[map_i]->b_data + map_b);
> - clu_bits &= last_bit_mask[last_mask];
> - count += used_bit[clu_bits];
> + bitmap = (void *)(sbi->vol_amap[map_i]->b_data + map_b);
> + clu_bits = lel_to_cpu(*(__le_long *)bitmap);
> + count += hweight_long(clu_bits &
> BITMAP_LAST_WORD_MASK(last_mask));
> }
>
> *ret_count = count;
> --
> 2.43.0
next prev parent reply other threads:[~2023-12-07 3:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20231205160306epcas1p35c3e3fc9ef2c8651eac58a8d6c194880@epcas1p3.samsung.com>
2023-12-05 15:58 ` [PATCH v3] exfat/balloc: using hweight instead of internal logic John Sanpe
2023-12-07 2:40 ` Sungjong Seo [this message]
2023-12-07 12:38 ` Namjae Jeon
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=1461149300.81701918783708.JavaMail.epsvc@epcpadp4 \
--to=sj1557.seo@samsung.com \
--cc=Andy.Wu@sony.com \
--cc=Wataru.Aoyama@sony.com \
--cc=cpgs@samsung.com \
--cc=linkinjeon@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sanpeqf@gmail.com \
--cc=willy@infradead.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 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).