Ok. Sorry
> > a vm layer to balance them. Linus just blew away a ton of this kind of mess
> > in the VM with user pages. Don't reinvent the problems some older BSDs had
>
> Ehm I didn't notice the VM layer used slab constructors/destructors in
> any way.
If you have a big pile of lists of free objects just in case you eventually
have to have scavenging routines to get them back on tight memory. BSD for
example recovers mbufs (sk_buff equivalents) when there is a memory shortage,
this means it asks each protocol to ask each of its sockets if it can get
stuff back (ick...). Then there is the "who shall I ask first" question.
(Current BSD this isnt paticularly bad btw)
> > However anyone who blithely throws slab out without doing serious benchmarks
> > on high end network performance is a fool. Furthermore 2.2 is not the time
>
> Please tell me what was there to benchmark it? Are you going to
> impress me with the network statement? That's not that easy :-).
Packets per second with slab versus without.
> With one exception nobody stepped in and used this feature!
> Look at the patch the constructor usage there was just preventing
> a hand full of zero initializations, just about 8 or 10 (frankly I don't
> remember exactly), which looked the following way around:
Im not arguing about removing the constructors. We don't use them, why keep
them. They can be put back if/when used. Slab itself is a different matter
>From thje other paragraph I think I just got the wrong end of the stick. Its
removing slab I don't want to see, not removing pointless constructors.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/