Results 1 to 3 of 3

Thread: Optimizing RAM and File Allocation

  1. #1
    agauthier Guest

    Default Optimizing RAM and File Allocation

    RAM Memory Optimization

    When you are coming close to the end of developing your application, it is time to verify how much RAM memory is being taken by the system.

    The following cases demonstrates how modifying ROOTFS_SIZE will have an impact on RAM availability.

    Case 1 : ROOTFS_SIZE=130000

    In the <PADS>/Makefile
    ROOTFS_SIZE=130000

    On the Warp run the df command
    # df -h
    Filesystem Size Used Available Use% Mounted on
    /dev/ram0 126.6M 109.3M 11.0M 91% /


    On the Warp run the free command
    # free
    total used free shared buffers
    Mem: 257028 237904 19124 0 130000
    Swap: 0 0 0
    Total: 257028 237904 19124



    Case 2 : ROOTFS_SIZE=120000

    Now if we rebuild and modify the Makefile to
    ROOTFS_SIZE=120000

    On the Warp run the df command
    # df -h
    Filesystem Size Used Available Use% Mounted on
    /dev/ram0 116.8M 107.5M 3.5M 97% /


    On the Warp run the free command
    # free
    total used free shared buffers
    Mem: 257028 229988 27040 0 120000
    Swap: 0 0 0
    Total: 257028 229988 27040



    So by decreasing the ROOTFS_SIZE we can notice that the RAM available on /dev/ram0 has decreased from 11.0M to 3.5M. On the other hand the amount of free buffers has increaed from 19124 blocks to 27040 blocks (where 1 block = 1024 bytes).
    The fact that the /dev/ram0 has decreased means that there is less space available to add files into the ramdisk partition. On the other hand, there is more RAM available for the OS to use for applications to use.



    Inode (Maximum number of files)

    Another part of the system which is important is the amount of inodes being allocated for the system, essentially dictating how many files can be created on the system.

    The following cases demonstrates how modifying the genext2fs -i parameter will have an impact on the maximum number of inodes available for the kernel.

    Case 1 : -i 2264
    In the Makefile, set the following (btw, adding the -v parameter will give your additional info when the makefile is built) :
    In the Makefile, add the following:
    image: $(TARGETS_IMAGE)
    genext2fs -U \
    -d build_warp/root \
    -b $(ROOTFS_SIZE) \
    -i 2264 -v \


    When running 'make image' will indicate the following:
    #make image
    genext2fs -U \
    -d build_warp/root \
    -b 120000 \
    -i 2264 -v \
    images/rootfs.img
    120000 blocks (8253 free, 6000 reserved), first data block: 1
    2280 inodes (139 free)
    block size = 1024, frag size = 1024
    number of groups: 15
    8000 blocks per group,8000 frags per group,152 inodes per group
    Size of inode table: 19 blocks



    Case 2 : -i 2300
    In the Makefile, set the following (btw, adding the -v parameter will give your additional info when the makefile is built) :
    In the Makefile, add the following:
    image: $(TARGETS_IMAGE)
    genext2fs -U \
    -d build_warp/root \
    -b $(ROOTFS_SIZE) \
    -i 2300 -v \


    When running 'make image' will indicate the following:
    # make image
    genext2fs -U \
    -d build_warp/root \
    -b 120000 \
    -i 2300 -v \
    images/rootfs.img
    120000 blocks (8238 free, 6000 reserved), first data block: 1
    2400 inodes (259 free)
    block size = 1024, frag size = 1024
    number of groups: 15
    8000 blocks per group,8000 frags per group,160 inodes per group
    Size of inode table: 20 blocks



    When running with -i 2264, genext2fs will round up to 2280 inodes of which 139 free ones can be additionaly created at run time.

    When running with -i 2300, genext2fs will round up to 2400 inodes of which 259 free ones can be additionaly created at run time.


    Please note that the "-i inodenumber" will affect the number of free blocks that are available.

  2. #2
    Join Date
    Jul 2008
    Posts
    268

    Default

    Great article Alain. To put this all in context the first portion of this post show how to optimize RAM usage by 're-claiming' RAM on the appliance. In other words, it will allow you to increase the amount of available RAM during runtime. Very useful if you find all your applications are consuming a lot of RAM and you begin to approach the 256 Mb RAM limit.

    The basic idea is that as part of the original design of the appliance the size of what the ramdisk took in RAM was hard-coded to a large value (130 Mb) to accomodiate most scenarios. However any unused portion of ramdisk is allocate upfront in RAM is unfortunately not accessible at runtime. So even if your ramdisk only required 70 Mb (after decompression), a full 130 Mb is allocated and removed from available RAM at runtime. The article above shows how to optimize and only pre-allocate the amount of RAM for ramdisk that you need for your specific application. This should likely only be done once you have finished application development.

  3. #3
    Join Date
    Jul 2008
    Posts
    268

    Default

    RAM optimization is now done automatically in PADS release 2.1. It is no longer necessary to change the parameters mentioned in this post.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •