Re: Examining the VM splay tree effectiveness

From: Andre Oppermann <andre_at_freebsd.org>
Date: Fri, 01 Oct 2010 00:06:54 +0200
On 30.09.2010 23:44, Andre Oppermann wrote:
> On 30.09.2010 20:04, Roman Divacky wrote:
>> On Thu, Sep 30, 2010 at 07:49:00PM +0200, Roman Divacky wrote:
>>> On Thu, Sep 30, 2010 at 07:46:32PM +0200, Andre Oppermann wrote:
>>>> On 30.09.2010 19:24, Roman Divacky wrote:
>>>>> are you aware of Summer of Code 2008 project by Mayur Shardul?
>>>>
>>>> I remember that there was this project but I never saw any numbers
>>>> or other outcome of it. Haven't checked p4 to look at the code
>>>> though.
>>>
>>> there's a little something:
>>>
>>> http://wiki.freebsd.org/MayurShardul/VM_Algorithm_Improvement
>>
>> and the actual patch + userspace implementation + benchmarking suite
>> is here:
>>
>> http://code.google.com/p/google-summer-of-code-2008-freebsd/downloads/detail?name=Mayur_Shardul.tar.gz&can=2&q=
>>
>>
>> it looks like a solid work with solid results to me
>
> I just took a look (not in-depth though) at the patch and can't follow
> your conclusion. It is not ready to go into svn in its current state.
>
> Even though it is called a radix trie it doesn't look like one. On first
> impression it looks much more like an AA tree. A radix trie, which we
> already have in our network routing table code, is a variable length
> (mask) tree that does path compression. See net/radix.[ch] and
> http://en.wikipedia.org/wiki/Radix_tree

Thinking more about this I can't see any advantage of the radix trie
becoming useful for the vmmap.  The index of the vmmap is the address
range and can't be expressed in a path compressable power of 2 quantity
and is non-overlapping.  The key for the trie, a pointer, has a fixed
small size and can't be optimized away.  And it is not a balanced tree.
Many keys in the same region lead to long node traversals.

In short: VMmap and a radix trie have an impedance mismatch and are unfit
for each other imho.

-- 
Andre
Received on Thu Sep 30 2010 - 20:06:56 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:07 UTC