>The last week I implemented from scratch RB-trees. Then I changed the
>kernel to use them in the page cache (I killed the page_hash_table). Via
I am writing this with also the buffer cache in a rb-tree of rb-tree.
The buffer cache is a bit slower using rb than using the hashtable
(eveything rock solid though). The numbers of hdparm -T are 116Mbyte/sec
of the hashtable against 104Mbyte/sec of the double rb structure.
I think that removing the double rb-tree and making it a whole (one)
buffer-rb-tree for _all_ the buffer cache will make performances closer to
the hashtable method. Probably I should do that also for the page cache (a
whole rb instead of a per-inode rb). A whole rb for all the page cache but
with a primary and a secondary key (right now my rb implementation has
only one key hardwired in the rb_node_t...). To make the code more generic
I can't use a real callback for the compare method (too slowww) so I'll
have to use some #define trick...
But before spend more time on this RB-way I would like to hear comments...
I know Chuck was going to play a bit with my first RB page cache patch.
How does it performs on high memory? I think that if the RB-page-cache is
at least as fast as the hashtable-page-cache we could/should move to RB. I
see the RB way far more cleaner on the long run (for example no need of
ugly dynamic hashtable resizing on high memory machines, no need of
large hashtables maybe always left unused). 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/