Hi
Okay��I think I realy understand this problem. The point I think is all free
objects are linked by index number, the first one's index is stored in
slabp->free, and the first one's object descriptor stores the next one's
index, and so on!
You finally get the picture :)
regards,
Mulyadi
Hi again..
> Maybe your explanation is reasonable.
> But I still can not understand why it put the last free object forward as
> the first and the current released object as the second? Is it redundant?
I forgot to add something. Current released object index (number) is
recorded, so that it wil
Hi...
Maybe your explanation is reasonable.
But I still can not understand why it put the last free object forward as
the first and the current released object as the second? Is it redundant?
Oh no, that's not what I meant. Current released object number is
assigned to the slab's free desc
Hi...
there
are codes like the following which I can not understand:
unsigned int objnr = obj_to_index(cachep, slabp, objp);
slab_bufctl(slabp)[objnr] = slabp->free;
slabp->free = objnr;
slabp->inuse--;
and slab_bufctl(slabp) is (kmem_bufctl_t *)(slabp + 1).
Sinc
Hi, all
In the function call chain
kmem_cache_free()->cache_flusharray()->free_block()->slab_put_obj(), there
are codes like the following which I can not understand:
unsigned int objnr = obj_to_index(cachep, slabp, objp);
slab_bufctl(slabp)[objnr] = slabp->free;
slabp-
