Messages in this thread | | | Date | Tue, 27 Apr 1999 21:00:50 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [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...).
Comments?
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/
| |