Virtual Memory - Embedded

This is a discussion on Virtual Memory - Embedded ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Virtual Memory

  1. Virtual Memory

    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.

    Thanks.

  2. 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
    (or unavailable).
    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
    sufficient amount
    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
    more memory
    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.


    Glen




    On Aug 4, 1:09 pm, NewToEmbeddedLinux wrote:
    > 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.
    >
    > Thanks.



  3. 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
    memory?

    Thanks,
    Eswar.

  4. Re: Virtual Memory

    And what other alternatives we have for flash drives?

  5. Re: Virtual Memory

    Yes, memory is restricted to storage plus real memory, less the
    kernel's overhead.

    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
    exception.

    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:

    pvoid BigMemoryChunk;

    and it would mean nothing, and not take up any memory, until you
    said :

    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.

    G

    On Aug 4, 3:01 pm, NewToEmbeddedLinux wrote:
    > 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
    > memory?
    >
    > Thanks,
    > Eswar.



+ Reply to Thread