Re: [RFC] My research agenda for 2.7

[William Lee Irwin III <wli@holomorphy.com>]

On Wednesday 25 June 2003 03:10, William Lee Irwin III wrote:
>> It severely limits its usefulness. Dropping in a more flexible data
>> structure should be fine.

On Wed, Jun 25, 2003 at 03:25:47AM +0200, Daniel Phillips wrote:
> Eventually it could well make sense to do that, e.g., the radix tree 
> eventually ought to evolve into a btree of extents (probably).  But making 
> things so complex in the first version, thus losing much of the incremental 
> development advantage, would not be smart.  With a single size of page per 
> address_space,  changes to the radix tree code are limited to a couple of 
> lines, for example.
> But perhaps you'd like to supply some examples where more than one size of 
> page in the same address space really matters?

Software-refill TLB architectures would very much like to be handed the
largest physically contiguous chunk of memory out of pagecache possible
and map it out using the fewest number of TLB entries possible. Dropping
in a B+ tree to replace radix trees should be a weekend project at worst.
Speculatively allocating elements that are "as large as sane/possible"
will invariably result in variable-sized elements in the same tree.


-- wli