Messages in this thread | | | From | (Alan Cox) | Subject | Re: PATCH killing dead code and design errors in pre6 | Date | Wed, 13 Jan 1999 19:27:59 +0000 (GMT) |
| |
> My notes about the free lists should be primary seen as a hint on about > which *fundamental* changes to the design of the kernel would be needed > to make actuall use of something like the slab constructor/destructor > mechanism. Quite the opposite way around also.
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/
| |