>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 killedby mistake. Note also that with a better design you won't need to setflushtime to zero anymore. Look at my buffer.c to see my redesign offlushtime.

>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 alwaysrequest data that has no reason to be cached (this at least in ext2) andin 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_tablewithout the b_count++, if you then sleep your buffer could be freed underyou.

>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" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/