Messages in this thread | | | Date | Wed, 14 Apr 2004 10:29:51 +0200 | From | Jens Axboe <> | Subject | Re: [PATCH] conditionalize some boring buffer_head checks |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |