[lkml]   [1999]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.2.8_andrea1.bz2
On Thu, 13 May 1999, Chuck Lever wrote:

>hadn't seen a recent version of your patch... but that sounds like a good

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

>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)
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

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

>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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.492 / U:1.528 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site