>hadn't seen a recent version of your patch... but that sounds like a good
>design.
Thanks :-).
>correct, there are no changes in getblk() 2.2.7 -> 2.2.8. however, if
>flushtime is no longer relevant, then this piece of code is now
Ah ok, that was my complain too but I think that flushtime is been killed
by mistake. Note also that with a better design you won't need to set
flushtime to zero anymore. Look at my buffer.c to see my redesign of
flushtime.
>in fact, under most circumstances, this code is exercised relatively
>rarely, compared to the rate that getblk() is called. so this might be
>even cooler:
>
> bh = find_buffer(dev, block, size);
> if (bh) {
> bh->b_count++;
> return bh;
> }
For the record this is my current getblk:
bh = find_buffer(dev, block, size);
if (bh)
{
bh->b_count++;
touch_buffer(bh);
return bh;
}
touch_buffer is strictly needed before returning from getblk.
get_hash_table and find_buffer when they are recalled alone, they always
request data that has no reason to be cached (this at least in ext2) and
in general getblk seems the right place for touching the buffer.
>but i don't know what that might do to maintainability; there is a cryptic
>comment next to get_hash_table() about avoiding race conditions, so
>somehow this bit of code may need to change if get_hash_table() ever
>changes.
I think the comment refers about the b_count++. If you do a get_hash_table
without the b_count++, if you then sleep your buffer could be freed under
you.
>that there's still a change in 2.2.8 that is throttling performance. when
>that is resolved, i will try another benchmark.
Ok ;)..
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/