Re: [PATCH] conditionalize some boring buffer_head checks

[Jens Axboe]

On Wed, Apr 14 2004, Jeff Garzik wrote:
> 
> These checks are executed billions of times per day, with no stack dump 
> bug reports sent to lkml.  Arguably, they will only trigger on buggy 
> filesystems (programmer error), and thus IMO shouldn't even be executed 
> in a non-debug kernel.
> 
> Even though BUG_ON() includes unlikely(), I think this patch -- or 
> something like it -- is preferable.  The buffer_error() checks aren't 
> even marked unlikely().
> 
> This is a micro-optimization on a key kernel fast path.

As Andrew mentioned, this isn't a fast path at all. You are potentially
even going to block on this call, and even if you don't you'll end up
spending a butt load of cycles in the io scheduler.

> ===== fs/buffer.c 1.237 vs edited =====
> --- 1.237/fs/buffer.c	Wed Apr 14 03:18:09 2004
> +++ edited/fs/buffer.c	Wed Apr 14 03:39:15 2004
> @@ -2688,6 +2688,7 @@
>  {
>  	struct bio *bio;
>  
> +#ifdef BH_DEBUG
>  	BUG_ON(!buffer_locked(bh));
>  	BUG_ON(!buffer_mapped(bh));
>  	BUG_ON(!bh->b_end_io);

The last one will be 'caught' at the other end of io completion, so I
guess that could be killed (even though you already lost the context of
the error, then). The first two are buffer state errors, I think those
should be kept unconditionally.

> @@ -2698,6 +2699,7 @@
>  		buffer_error();
>  	if (rw == READ && buffer_dirty(bh))
>  		buffer_error();
> +#endif

I'm fine with killing the buffer_error(), maybe

	if (rw == WRITE && !buffer_uptodate(bh))
		buffer_error();

should be kept though.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/