> > 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/