Re: [PATCH] Btrfs: do not async metadata csums if we have hardware crc32c

[Arne Jansen <sensille@gmx.net>]

On 09/24/12 20:11, Josef Bacik wrote:
> The reason we offload csumming is because it is CPU intensive, except it is
> not on modern intel CPUs.  So check to see if we support hardware crc32c,
> and if we do just do the csumming in our current threads context.  Otherwise
> we can farm it off.  Thanks,
> 
> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
> ---
>  fs/btrfs/disk-io.c |   17 +++++++++++++++++
>  1 files changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index dcaf556..830b9af 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -31,6 +31,7 @@
>  #include <linux/migrate.h>
>  #include <linux/ratelimit.h>
>  #include <asm/unaligned.h>
> +#include <asm/cpufeature.h>
>  #include "compat.h"
>  #include "ctree.h"
>  #include "disk-io.h"
> @@ -880,6 +881,22 @@ static int btree_submit_bio_hook(struct inode *inode, int rw, struct bio *bio,
>  	}
>  
>  	/*
> +	 * Pretty sure I'm going to hell for this.  If our CPU can do crc32cs in
> +	 * the hardware then there is no reason to do the csum stuff
> +	 * asynchronously, it will be faster to do it inline, so test to see if
> +	 * our CPU can do hardware crc32c and if it can just do the csum in our
> +	 * threads context.
> +	 */
> +#ifdef CONFIG_X86
> +	if (cpu_has_xmm4_2) {
> +		printk(KERN_ERR "doing it the fast way\n");

You'll probably go to hell for the printk...

> +		ret = btree_csum_one_bio(bio);
> +		if (ret)
> +			return ret;
> +		return btrfs_map_bio(BTRFS_I(inode)->root, rw, bio, mirror_num, 0);
> +	}
> +#endif
> +	/*
>  	 * kthread helpers are used to submit writes so that checksumming
>  	 * can happen in parallel across all CPUs
>  	 */
>