Re: [PATCH v2] exfat/balloc: using hweight instead of internal logic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 05, 2023 at 12:33:05PM +0800, John Sanpe wrote:
> 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.

Have you run sparse over this?  "make C=2" will do it for you if you
have sparse installed.  I think it's going to complain about missing
endianness annotations.

> +	for (i = 0; i < total_clus; i += BITS_PER_LONG) {
> +		bitmap = (void *)(sbi->vol_amap[map_i]->b_data + map_b);
> +		clu_bits = lel_to_cpu(*bitmap);

I understand why you need to byteswap at the end, but I don't understand
why you need to byteswap here.  You're asking how many bits are set,
and that's the same answer no matter whether you calculate it on
0x12345678 or on 0x78563412.

> +++ b/fs/exfat/exfat_fs.h
> @@ -136,6 +136,7 @@ enum {
>  #define BITMAP_OFFSET_BYTE_IN_SECTOR(sb, ent) \
>  	((ent / BITS_PER_BYTE) & ((sb)->s_blocksize - 1))
>  #define BITS_PER_BYTE_MASK	0x7
> +#define BITS_PER_LONG_MASK	(BITS_PER_LONG - 1)

I don't think this adds any value over just using (BITS_PER_LONG - 1)
directly.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux