[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclinux-dev
Subject:    Re: [uClinux-dev] memory free
From:       Prasad <ndprasad () gmail ! com>
Date:       2009-04-29 23:01:08
Message-ID: 3351bfbe0904291601p37ca69cds45adef318a931a1d () mail ! gmail ! com
[Download RAW message or body]

Doing some more experiments, i figure out as soon as it hits the full
memory (show by "free"), it the kernel goes and does some cleaning
stuff on the already freed memory for any new memory requirement.

So essentially "free" (or /proc/meminfo) doesn't tell me that the
memory is being used by some other process that is running or the
process that was using but got killed and the kernel has not recovered
the memory yet.  Is my understanding right?

Is there any document that describes how the memory allocation scheme
works in uclinux compared to linux in a little more detailed?.

Thanx
- Prasad


On Tue, Apr 28, 2009 at 11:55 PM, Prasad <ndprasad@gmail.com> wrote:
> Interesting..Just for understanding, in the test code in the loop i
> malloc-ed to the size of the current loop count (and didn't free it).
> After it allocates close to 75% of the available memory i killed the
> task and observed whether the "free" memory decreases. It didn't. Till
> now i was under impression that this would have fragmented memory but
> it will still be still available for other task although fragmented.
> But from your comments it seems it is more complex than that.
> 
> So is there any house keeping kernel function scans and marks the page
> used by the killed process as free? Is there any way to force it to do
> that immediately? Or does it do periodically ?
> 
> Thanx
> - prasad
> 
> > 
> > Yes, but with some caveats.
> > 
> > IIRC all processes (and the kernel) under uClinux share a common memory "pool" (a \
> > side effect of having no MMU).  So in physical memory the heap allocations for \
> > your process will be interleaved with allocations from other processes and the \
> > kernel itself.  This in turn means that when the process exits, the kernel will \
> > indeed release all of the memory assigned to the process, but may not be able to \
> > release all the newly-allocated pages (since other processes may still be using \
> > pieces of them).  So the memory usage may be a bit higher than before due to the \
> > page housekeeping information. 
> > I think :)
> > 
> > 
> > _______________________________________________
> > uClinux-dev mailing list
> > uClinux-dev@uclinux.org
> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> > This message was resent by uclinux-dev@uclinux.org
> > To unsubscribe see:
> > http://mailman.uclinux.org/mailman/options/uclinux-dev
> > 
> 
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


[prev in list] [next in list] [prev in thread] [next in thread]