[lkml]   [1999]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [big performances boost for DataBases] Re: cache killer memory death test - 2.0 vs 2.2 vs arca - programs inside
On Mon, 26 Apr 1999, Stephen C. Tweedie wrote:

>Excellent. Do you have an idea of what exactly makes the difference?
>It looks as if the buffer write scheduling is making a large difference:
>there isn't _that_ much difference in system time in .arca2.

It depends what you are benchmarking. If you are benchmarking a piece of
code that rewrite in the same place many times, yes, definitely my
redesign of the flushtime handling is the the big difference (it will
completly avoids tons of not needed I/O). But all my other VM ideas/code
are very connected with performances. Today I think to have removed all
the code I was not sure it was making difference or not (it wasn't making
difference infact ;).

BTW, I have news about RB-trees. I did some benchmark and they are
_definitely_ slower in the buffer cache for query (now find_buffer is far
from the top of the profiling output). Now I am using the hash function
of the stock kernel, but I'll move to the mul method shortly.

I am quite sure that I was going very slow also in the page cache because
I was using a whole RB-tree for all the page cache.

So now I am running with per-inode RB-trees for the page cache and
hashtable in the buffer cache and performances seems great. I still think
per-inode rb-trees (my original idea) are the better struct for fast query
on inode pages on any kind of RAM sizes. Insert/delete time is never been
an issue (maybe because I/O is so slow?).

If you want I can still produce a standalone page-cache-per-inode rb-tree
patch, but the only difference between the version just benchmarked by
Chuck and my current RB-tree code is that now I inlined everything (maybe
it will be a bit worse or a bit better but not a big issue also
considering that it's common code...).


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.124 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site