On Fri, 6 Apr 2007, Andrew Morton wrote:
> urgh. It would be better to continue to rework slab/slub callers in the
> fashion which you have been doing, don't you think?
Yes definitely but I do not want to risk getting slub dropped from mm.
> Rephrasing my earlier point: are we doing things in the correct order here,
> and efficiently? It is not settled in my mind whether we want to merge
> slub _at all_. Do we have enough information yet to be able to make that
> decision?
Check the initial SLUB_V6 patch? It has long list of issues that were
addressed.
> And if that information indicates that a slub merge _is_ justified, why is
> the chosen approach superior to the incremental one: if slab code is grotty
> (it is), clean it up. If slab has unnecessary stuff, delete it.
SLUB is a fundamentally different design. We can address some of the
warts in SLAB as we do the cleanup but the basic way of handling objects
on queues is core to SLAB and is not used at all in SLUB.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
