On Wednesday 25 June 2003 03:10, William Lee Irwin III wrote:

quoted

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