On Sunday, January 28, 2001 02:29:09 PM +1100 Andrew Morton
<[EMAIL PROTECTED]> wrote:
> Shawn Starr wrote:
>>
>> Andrew, the patch HAS made a difference. For example, while untaring
>> glibc-2.2.1.tar.gz the system was not sluggish (mouse movements in X)
>> etc.
>>
>> Seems to be a go for latency improvements on this system.
>
> hmm.. OK, thanks.
>
> Chris, this seems to be a worthwhile improvement to mainstream
> reiserfs, independent of the low-latency thing. You can
> probably achieve 10 milliseconds with just a few lines of
> code - a subset of the patch which Shawn tested. (Unless you
> were planning on magical algorithmic improvements...).
>
> I'm all set up to generate those few lines of code, so
> I'll propose a patch later this week.
Perfect, I was thinking exactly the same thing. We have to be careful here
though, since the extra schedules will increase the chance the searching
has to be redone from scratch, which can have big performance ramifications.
I think your change to search_by_key will be the safest for performance
considerations, along with the change to prepare_for_delete_or_cut. If
those won't be enough, we can attack reiserfs_get_block (who is probably
the biggest single offender without your patch).
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
