>Is there no chance to get this broken down? It's impossible to do
>performance comparisons of things like the rb tree stuff against hash
>improvements if we have to deal with changes in as large a block as
>this.
Agreed. I just said Chuck that I would have extracted the rbtree patch
against 2.2.6. I _completly_ agree and right now I am also _very_ worried
by performances of RB in the buffer cache. The rb-cache per-inode is
almost sure a win according to me, but a global RB for all the page cache
and one for all the buffer cache (as I am running now) is not so obviously
a win and need accurate testing. With a global RB for all the buffer cache
I get my usual 116mbyte/sec of hdparm -T (as with the hash table). gdbm
software seems to stess them really a lot, but I never run on a 2.2.6 with
only my rb-tree patch so I don't know if the rb are a bottleneck (as it
seems) or if they are just rasonable fast.
andrea@laser:/tmp$ readprofile -m /System.map | sort -r | head -10
6231 total 0.0108
606 flush_dirty_buffers 1.6833
445 find_buffer 5.8553
^^^^^^^^^^^
336 ext2_alloc_block 1.2000
299 try_to_identify 0.2679
191 make_request 0.1098
180 do_anonymous_page 1.5000
177 getblk 0.2281
167 get_hash_table 8.3500
^^^^^^^^^^^^^^
158 si_meminfo 1.2344
(try to identify is a boot thing, ignore it)
Ah and I am worried only by find time not by insert/delete time.
insert/delete time seems perfectly OK.
Tomorrow I'll try to find the time to generate a rb-patch for 2.2.6 with
all the page cache in one rbtree. And one second incremental incremental
against the first one that will put also the buffer cache in a
separate rbtree.
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/