[uClinux-dev] Reclaiming Memory

[Harry Gunnarsson]

I see, assuming that the algorithm works as you lay out, for embedded usage
I would have preferred the fixed allocation scheme I first expected from
SLAB. And it would have been even better if one could select the number of
chunks of each size and fine tune it to its system (like OSE RTOS...)
Well, the simple and obvious solution for me, which probably is fine on our
32 M system, would be to hold on to the big buffers once I got them

Gavin, thanks for your insight.
Harry

On 11/1/07, Gavin Lambert <gavinl at compacsort.com> wrote:
>
> Quoth Harry Gunnarsson:
> > Hm, you are saying one thing that gets me thinking. I assumed,
> > perhaps incorrectly, that the 'chunks' of memory in the
> > power-of-two scheme were pre-allocated at kernel start.
> > That is, n * 128k, m * 256k, y * 512k etc And I thought that
> > the big chunks of 2M and 4M were also pre-allocated at startup
> > and never used for small allocations.
> >
> > I thought that this was the point of the SLAB allocator, i.e.
> > avoiding fragmentations with fixed size pre-allocated blocks.
>
> Well, I'm not entirely certain how the SLAB allocator operates, since I
> haven't really looked at its code at all.  But I do know (from testing)
> that
> larger blocks can be chosen and sliced to create smaller blocks.  I don't
> know what its criteria is for choosing blocks; my *assumption* is that it
> walks up the chain (ie. if it needs a 256k block, it'll look in the 256k
> free list, and only if there aren't any will it go up to the 512k free
> list,
> and so on until it finds a block it can slice up and distribute).  But I
> really don't know.  Maybe it tries to do something clever instead.
>
> > So there is no 'guaranteed' way of making sure the system can
> > deliver reliably a 4M chunk of memory over the time of execution, right?
>
> If you want to absolutely guarantee it, then don't let Linux have the RAM
> in
> the first place :)  (Either by lying to it about how much RAM is there or
> by
> using something like the bootmem interface.)  Usually you don't need to go
> that far, though.
>
>
>
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev at uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev at uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20071102/0fbbb222/attachment.html