Messages in this thread |  | | Date | Wed, 13 Jan 1999 20:18:33 +0100 | | From | Marcin Dalecki <> | | Subject | Re: PATCH killing dead code and design errors in pre6 |
| |
Alan Cox wrote:
> > Then why not just maintain a free list inside skbuff.c? Very same like > > all the other parts of the kernel are doing. > > No. Thats not what slab is all about. Read the papers.
I did read it! I did read it! I did... and I still don't buy much of the claims made there without looking at the context of usage.
> > > it is possible to avoid the copying of the files array on forking for most cases. > > > > Same again... use a free list. > > A free list doesnt do cache optimisations. I think you should read the > papers on SLAB before you do anything more than remove dead constructor > code. Also do you want 300 free lists in the kernel. Then you can write
No certainly I don't want. The places where those are used are rare in linux. And this is actully how linux is dealing with the problem already. It just turns out there there isn't that much of place to do reusal at all. 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.
In case of skbuff I didn't mean it serious. It's not worth it.
> 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.
> with 400 different ways to reclaim mbufs on a bad day. > > I'd agree the slab code is messy, I can see the argument for removing the > un-needed constructors and that seems fine, someone can put it back nicely > when they use it. That bit makes sense. > > 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 :-).
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:
boo->blah = NULL; boo->bang = NULL; boo->bar = 0; boo->geek = 0; ...
This translated into code wasn't justifying any serious trouble to trying to avoid it: Compare this please to the cost to check *everywhere* for the presence of a constructor or destructor and then actually calling it in case of need. Oh of course it's harder to count this penaly in cycles together. (I certainly know you can imagine the very very sparse code the compiler is making out of the stuff shown above. MV &BOO --> X XOR AX, AX MV AX *X, ++X MV AX *X, ++X ... ) And at the other place it invented some "write only" operations. However I'm fully aware about the fact that the other place was less common.
> to be trying to throw out slab. 2.3 is the time to try and throw it out > by proving you can consistently beat it.
I didn't mean to throw it out *entierly*. What I'm primarly after is removing carfully all the unneded stuff for the *STABLE* release. I don't like to see a *STABLE* productivity release containing unused (and therefore not seriously tested code). And on the way of doing this I would certainly like to reorder, squezze, tweak some stuff in it. I'm certainly aware about the fact that there is need for stability in first place now.
BTW> I don't see the need for a TBit betwork in my home to do some serious benchmarking. And I have some real worlds MBits at hand in work :-).
Second please have a look at the places where I have added some comments about the usage of the other remaining parameters to kmem_cache_create(). They show quite clear, that there seems to be at least a little confusion about what they are actually usefull for. And as long as long the confusion remains there are no chances they will be used properly.
--Marcin
- 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/
|  |