Folks
I am attaching the benchmark results for Page Cache Implementation
using B-trees. I basically ran the tio (threaded i/o) benchmark
against my kernel (with the B-tree implementation) and the Linux
kernel shipped with FC5. Radix tree implementation is definately
better however the B-tree implementation did not suck that bad :)
Also I attaching a new patch which was used for measuring the
benchmarks. Also henceforth changes to the page will be tracked using
the projected hosted at http://code.google.com/p/btreepc
Thanks
- Vishal
--
Motivation will almost always beat mere talent.
Vishal Patil wrote:
> Folks
>
> I am attaching the benchmark results for Page Cache Implementation
> using B-trees. I basically ran the tio (threaded i/o) benchmark
> against my kernel (with the B-tree implementation) and the Linux
> kernel shipped with FC5. Radix tree implementation is definately
> better however the B-tree implementation did not suck that bad :)
>
> Also I attaching a new patch which was used for measuring the
> benchmarks. Also henceforth changes to the page will be tracked using
> the projected hosted at http://code.google.com/p/btreepc
>
Thanks for this. I guess a purist would say that you need to run against
the base kernel and base kernel plus your patches, but these numbers are
certainly enough to support your conclusion.
What's next?
--
Bill Davidsen <[email protected]>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
"Vishal Patil" <[email protected]> writes:
> I am attaching the benchmark results for Page Cache Implementation
> using B-trees. I basically ran the tio (threaded i/o) benchmark
> against my kernel (with the B-tree implementation) and the Linux
I suppose you'll need some more varied benchmarks to get
more solid data.
> kernel shipped with FC5. Radix tree implementation is definately
> better however the B-tree implementation did not suck that bad :)
Have you considered trying it again instead of radix tree with
another data structure? There are still plenty of other big
hash tables in the kernel that might benefit from trying
a different approach:
> dmesg | grep -i hash
PID hash table entries: 4096 (order: 12, 131072 bytes)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Mount-cache hash table entries: 256
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
e.g. the dentry/inode hashes are an obvious attack point.
Of course you'll need benchmarks that actually stress them.
-Andi
Hey Andi....This is useful information....I will look into it and let
you know....
Many thanks.
- Vishal
On 18 Aug 2006 18:25:54 +0200, Andi Kleen <[email protected]> wrote:
> "Vishal Patil" <[email protected]> writes:
>
> > I am attaching the benchmark results for Page Cache Implementation
> > using B-trees. I basically ran the tio (threaded i/o) benchmark
> > against my kernel (with the B-tree implementation) and the Linux
>
> I suppose you'll need some more varied benchmarks to get
> more solid data.
>
> > kernel shipped with FC5. Radix tree implementation is definately
> > better however the B-tree implementation did not suck that bad :)
>
> Have you considered trying it again instead of radix tree with
> another data structure? There are still plenty of other big
> hash tables in the kernel that might benefit from trying
> a different approach:
>
> > dmesg | grep -i hash
> PID hash table entries: 4096 (order: 12, 131072 bytes)
> Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Mount-cache hash table entries: 256
> Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
> TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
> TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
> TCP: Hash tables configured (established 262144 bind 65536)
>
> e.g. the dentry/inode hashes are an obvious attack point.
>
> Of course you'll need benchmarks that actually stress them.
>
> -Andi
>
--
Motivation will almost always beat mere talent.