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>
Subject: RE: [PATCH] exfat/balloc: using ffs instead of internal logic
Date: Tue, 12 Dec 2023 10:15:49 +0900 [thread overview]
Message-ID: <1185d01da2c98$bdfee260$39fca720$@samsung.com> (raw)
In-Reply-To: <20231207234701.566133-1-sanpeqf@gmail.com>
> Replaced the internal table lookup algorithm with ffs of the bitops
> library with better performance.
>
> Use it to increase the single processing length of the
> exfat_find_free_bitmap function, from single-byte search to long type.
>
> Signed-off-by: John Sanpe <sanpeqf@gmail.com>
Looks good. Thanks for your patch.
Acked-by: Sungjong Seo <sj1557.seo@samsung.com>
> ---
> fs/exfat/balloc.c | 41 +++++++++++++++--------------------------
> fs/exfat/exfat_fs.h | 3 +--
> 2 files changed, 16 insertions(+), 28 deletions(-)
>
> diff --git a/fs/exfat/balloc.c b/fs/exfat/balloc.c index
> 3e3e9e4cce2f..4bacbb0cf5da 100644
> --- a/fs/exfat/balloc.c
> +++ b/fs/exfat/balloc.c
> @@ -14,29 +14,15 @@
> #if BITS_PER_LONG == 32
> #define __le_long __le32
> #define lel_to_cpu(A) le32_to_cpu(A)
> +#define cpu_to_lel(A) cpu_to_le32(A)
> #elif BITS_PER_LONG == 64
> #define __le_long __le64
> #define lel_to_cpu(A) le64_to_cpu(A)
> +#define cpu_to_lel(A) cpu_to_le64(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*/
> - 0, 1, 0, 2, 0, 1, 0, 4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2,/* 40 ~
> 59*/
> - 0, 1, 0, 6, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, 4,/* 60 ~
> 79*/
> - 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, 5, 0, 1, 0, 2,/* 80 ~
> 99*/
> - 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, 4, 0, 1, 0, 2, 0, 1, 0, 3,/*100 ~
> 119*/
> - 0, 1, 0, 2, 0, 1, 0, 7, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2,/*120 ~
> 139*/
> - 0, 1, 0, 4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, 5,/*140 ~
> 159*/
> - 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, 4, 0, 1, 0, 2,/*160 ~
> 179*/
> - 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, 6, 0, 1, 0, 2, 0, 1, 0, 3,/*180 ~
> 199*/
> - 0, 1, 0, 2, 0, 1, 0, 4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2,/*200 ~
> 219*/
> - 0, 1, 0, 5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, 4,/*220 ~
> 239*/
> - 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0 /*240 ~
> 254*/
> -};
> -
> /*
> * Allocation Bitmap Management Functions
> */
> @@ -195,32 +181,35 @@ unsigned int exfat_find_free_bitmap(struct
> super_block *sb, unsigned int clu) {
> unsigned int i, map_i, map_b, ent_idx;
> unsigned int clu_base, clu_free;
> - unsigned char k, clu_mask;
> + unsigned long clu_bits, clu_mask;
> struct exfat_sb_info *sbi = EXFAT_SB(sb);
> + __le_long bitval;
>
> WARN_ON(clu < EXFAT_FIRST_CLUSTER);
> - ent_idx = CLUSTER_TO_BITMAP_ENT(clu);
> - clu_base = BITMAP_ENT_TO_CLUSTER(ent_idx & ~(BITS_PER_BYTE_MASK));
> + ent_idx = ALIGN_DOWN(CLUSTER_TO_BITMAP_ENT(clu), BITS_PER_LONG);
> + clu_base = BITMAP_ENT_TO_CLUSTER(ent_idx);
> clu_mask = IGNORED_BITS_REMAINED(clu, clu_base);
>
> map_i = BITMAP_OFFSET_SECTOR_INDEX(sb, ent_idx);
> map_b = BITMAP_OFFSET_BYTE_IN_SECTOR(sb, ent_idx);
>
> for (i = EXFAT_FIRST_CLUSTER; i < sbi->num_clusters;
> - i += BITS_PER_BYTE) {
> - k = *(sbi->vol_amap[map_i]->b_data + map_b);
> + i += BITS_PER_LONG) {
> + bitval = *(__le_long *)(sbi->vol_amap[map_i]->b_data +
> map_b);
> if (clu_mask > 0) {
> - k |= clu_mask;
> + bitval |= cpu_to_lel(clu_mask);
> clu_mask = 0;
> }
> - if (k < 0xFF) {
> - clu_free = clu_base + free_bit[k];
> + if (bitval != ULONG_MAX) {
> + clu_bits = lel_to_cpu(bitval);
> + clu_free = clu_base + ffz(clu_bits);
> if (clu_free < sbi->num_clusters)
> return clu_free;
> }
> - clu_base += BITS_PER_BYTE;
> + clu_base += BITS_PER_LONG;
> + map_b += sizeof(long);
>
> - if (++map_b >= sb->s_blocksize ||
> + if (map_b >= sb->s_blocksize ||
> clu_base >= sbi->num_clusters) {
> if (++map_i >= sbi->map_sectors) {
> clu_base = EXFAT_FIRST_CLUSTER;
> diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h index
> a7a2c35d74fb..8030780a199b 100644
> --- a/fs/exfat/exfat_fs.h
> +++ b/fs/exfat/exfat_fs.h
> @@ -135,8 +135,7 @@ enum {
> #define BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent) (ent &
> BITS_PER_SECTOR_MASK(sb)) #define BITMAP_OFFSET_BYTE_IN_SECTOR(sb, ent) \
> ((ent / BITS_PER_BYTE) & ((sb)->s_blocksize - 1))
> -#define BITS_PER_BYTE_MASK 0x7
> -#define IGNORED_BITS_REMAINED(clu, clu_base) ((1 << ((clu) - (clu_base)))
> - 1)
> +#define IGNORED_BITS_REMAINED(clu, clu_base) ((1UL << ((clu) -
> +(clu_base))) - 1)
>
> #define ES_ENTRY_NUM(name_len) (ES_IDX_LAST_FILENAME(name_len) + 1)
> /* 19 entries = 1 file entry + 1 stream entry + 17 filename entries */
> --
> 2.43.0
next prev parent reply other threads:[~2023-12-12 1:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20231209203819epcas1p469c0aecdc6a27fff7895a93ed5f3c4ec@epcas1p4.samsung.com>
2023-12-07 23:47 ` [PATCH] exfat/balloc: using ffs instead of internal logic John Sanpe
2023-12-12 1:15 ` Sungjong Seo [this message]
2023-12-12 1:53 ` Matthew Wilcox
2023-12-12 16:10 ` Fredrik Anderson
2023-12-13 13:29 ` 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='1185d01da2c98$bdfee260$39fca720$@samsung.com' \
--to=sj1557.seo@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 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.