Re: [PATCH] conditionalize some boring buffer_head checks

Jens Axboe
2004-04-14T08:30:55Z

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