I read in the Linux Kernel/Device driver books that the address space
of even a single process can be much larger than physical memory. If
this is true and and if there are more than one process that use
bigger address space then where does the system store all contents for
each of these processes.
I have an embedded system with a 128 MB RAM and 256 MB Flash drive.
I have 10 processes with 100 MB address space in each of them.
Re: Virtual Memory
It stores it in a 'swap file'. Simply what swapping does is take code
and data, that the
kernel does not need 'locked' into memory, and 'swap' these memory
'pages' out to
a storage medium. The kernel will marks this memory (page) as swapped
So when a condition arises where the kernel (or an application) has to
access that memory, it
generates a 'page fault' when it attempts to access it, then looks to
see if there is a swap
entry for that memory, and if it finds a swap entry it loads the code
or data from the 'swap file'
into real memory (if there is available memiry), and then accesses
it. What I have said is an
over-simplification of the process.
However in your situation it won't work. Your real memory is 128MB,
and storage (256 MB)
give a total of 384MB. Subtract the Kernel image, and other
operational needs of the OS,
and you have about 350 MB available for swap use, and this assumes a
normal minimal system.
Your requirements are 1 gigabyte (100 MBx10), and so there is not a
of storage to support running 10 100 MB processes.
Time to revisit your design. If you expand your flash drive to about
2 GB or larger you may
have enough space to do what you want provided you do not have to lock
than you have real memory for. Just be aware that flash drives may
not be a good media for
swapping because of wear--leveling, and other design restrictions.
On Aug 4, 1:09 pm, NewToEmbeddedLinux <het...@yahoo.com> wrote:[color=blue]
> I read in the Linux Kernel/Device driver books that the address space
> of even a single process can be much larger than physical memory. If
> this is true and and if there are more than one process that use
> bigger address space then where does the system store all contents for
> each of these processes.
> For example:
> I have an embedded system with a 128 MB RAM and 256 MB Flash drive.
> I have 10 processes with 100 MB address space in each of them.
Re: Virtual Memory
So, is it safe to say that any system can handle only as much memory
as it has in RAM and the storage device put together.
Somewhere I read that in Linux malloc() always returns requested
memory. Here, Linux does not have to reserve physical memory until the
application starts writing to it.
So, in my example: Lets say I used up all the available memory and the
storage (for swap entries). At this stage a process allocates (through
malloc) about 30 meg memory. What happens when it starts writing this
Re: Virtual Memory
And what other alternatives we have for flash drives?
Re: Virtual Memory
Yes, memory is restricted to storage plus real memory, less the
Simply what happens with respect to memory real, and virtual (swapped)
is that once the kernel (that supports swapping) is initializing it
will look at two items, real memory and the size of its swapper. It
will then create a pool (or pools) of memory handles (I won't go into
details of their different types, and uses). Then the kernel loads
device drivers, and then these take their chunks of memory from the
pool(s). Once the system is up and running there will be memory
handles left over for applications. The kernel will allocate and
restrict how much memory an application can ask for or how many memory
handles it can have. So, this means that when applications run they
can not demand certain types of memory (like kernel memory), nor can
they allocate memory beyond the size of the heap that has been
allocated to them. This is done so that if an application gets too
memory hungry, it will either not run or generate a memory
malloc() returns a pointer to the beginning of the memory it
allocated. If the pointer is NULL it failed. Usually malloc will fail
if you ask it for more memory than the system has to allocate. This
is done to protect the kernel and other applications being run. What I
think you are talking about is memory being "enstanciated" versus
being "allocated". You can set up a pointer(s) in C/C++ but until you
assign memory to it, it is considered enstanciated but not allocated.
Once you malloc, or assign memory to that pointer, then it becomes
allocated. In other words it is simply a reference until there is an
assignment of some sort. So you could say in a program:
and it would mean nothing, and not take up any memory, until you
BigMemoryChunk = malloc (30000000); // it would try to allocate
Thirty Million bytes.
In your example, where memory and storage are exhausted, the malloc
(above) would fail, and return a NULL pointer. You shouldn't even get
the chance to write to that memory. If, by some fluke, or
shortcoming, in the OS or the compiler, it did return a pointer, it
would fail the moment you start writing to it.
Flash drives covers a fairly big segment of non-rotating storage
media. USB keyfobs, Solid State Drives (SSD), DiskOnChip, etc. all
fall under this definition.
On Aug 4, 3:01 pm, NewToEmbeddedLinux <het...@yahoo.com> wrote:[color=blue]
> So, is it safe to say that any system can handle only as much memory
> as it has in RAM and the storage device put together.
> Somewhere I read that in Linux malloc() always returns requested
> memory. Here, Linux does not have to reserve physical memory until the
> application starts writing to it.
> So, in my example: Lets say I used up all the available memory and the
> storage (for swap entries). At this stage a process allocates (through
> malloc) about 30 meg memory. What happens when it starts writing this