Messages in this thread | | | Date | Tue, 27 Apr 1999 02:38:02 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: 2.2.6_andrea2.bz2 |
| |
On Mon, 26 Apr 1999, Stephen C. Tweedie wrote:
>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/
| |