[uClinux-dev] Reclaiming Memory

[Harry Gunnarsson]

Thanks for your reply. I finally succeeded in my lobbying efforts of
increasing the RAM on our custom board from 16 M to 32M. This piece of
software didn't run at all on the 16 M board.
Our current software with download-uncompress feature integrated leaves
around 12-15M left after startup, I think (of which I need 2x4M)

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.
But if you are saying that earlier allocated blocks of memory could be
chopped up to smaller chunks later on in the execution, I will follow your
advice of claiming them at startup. Actually, I do so in one instance
already. With the 32M board revisions, this should be fine.

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?

Thanks,
Harry

On 11/1/07, Gavin Lambert <gavinl at compacsort.com> wrote:
>
> Quoth Harry Gunnarsson:
> > So here's the problem, if I run this download-uncompress routine
> > back-to-back, it always works fine the first time, but it could
> > bail on the second/third/fourth time due to allocation failure
> > on one of the big buffers I need. I never figured out why this
> > is and I haven't figured out how to circumvent this. Since I
> > have returned the buffers with free(), the system should be
> > able to hand them out again in the next malloc() call, right?
>
> How much "spare" RAM do you have?  Since the 5272 doesn't have an MMU, any
> large memory requests must be satisfied by a single contiguous block of
> memory.  If the block that you got last time has been broken up into
> smaller
> blocks (for smaller allocations) in the meantime then it will no longer be
> available for your big allocation (and due to memory fragmentation, may
> never be again).
>
> If you're trying to allocate a significant fraction of your total RAM in a
> large chunk then your best bet is to allocate it once at program startup
> and
> keep it around the whole time.  That way you're guaranteed that it'll
> always
> be available.  (Assuming, of course, that you know in advance how much
> room
> you'll need and that other processes won't start having RAM starvation
> from
> this.)
>
>
>
> _______________________________________________
> 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/20071101/9b9e3ac4/attachment.html