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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/