Thursday, 15 January 2015

Memory Managment in kernel

I am reading Linux Kernel Development for undertsanding memory managment in kernel

-kernel cannot easily deal with memory allocation errors, and the kernel often cannot sleep.

Pages
-The kernel treats physical pages as the basic unit of memory management.
-MMU smallest unit is pages
-Most 32-bit architectures have 4KB pages.
-64-bit architectures have 8KB pages.
-kernel represents every physical page on the system with a struct page structure.
<linux/mm_types.h>.
structpage {
              unsigned long  flags;
              atomic_t   _count;  //stores the usage count of the page(-1 no one use the
              atomic_t _mapcount;                                                                     page)
              unsigned long private;
              struct address_space *mapping;//page cache
              pgoff_t index;
              struct list_head lru;
              void *virtual;(//pointer to virtual address space//NULL if not permanently    mapped)
};

 page_count()
-this structure to keep track of all the pages in the system, because the kernel needs to know whether a page is free
-If page is not free kernel must know who owns the page.
- Possible owners include
user-space processes, dynamically allocated kernel data, static kernel code, the page cache, and so on.

Zones-Because of hardware limitations, the kernel cannot treat all pages as identical. Some pages,because of their physical address in memory, cannot be used for certain tasks.
-to overcome this limitation,the kernel divides pages into different zones(similar properties).

Linux has four primary memory zones:
ZONE_DMA—This zone contains pages that can undergo DMA.
ZONE_DMA32—Like ZOME_DMA, this zone contains pages that can undergo DMA.Unlike ZONE_DMA, these pages are accessible only by 32-bit devices. On some architectures, this zone is a larger subset of memory.
ZONE_NORMAL—This zone contains normal, regularly mapped, pages.
ZONE_HIGHMEM—This zone contains “high memory,” which are pages not permanently mapped into the kernel’s address space.
<linux/mmzone.h>.
-actual use and layout of the memory zones is architecture-dependent.
- 32-bit x86 systems, ZONE_HIGHMEM is all memory above the physical 896MB mark.
-The memory contained in ZONE_HIGHMEM is called high memory. The rest
of the system’s memory is called low memory.
- On x86, for example, ZONE_NORMAL is all physical memory from 16MB to 896MB.
-

Patching Xenomai with linux

Xenomai on the Beaglebone Black in 14 easy steps

EDIT: Mark wrote an updated guide here.
The BeagleBone Black is an amazingly cheap and powerful development platform that is being used by many people in a lot of projects. That was intentionally vague, because I know that if you ended up here you already know what a BeagleBone Black is.
In this post I’ll explain how I got Xenomai to run on my BeagleBone.
First of all I tried these instructions, but couldn’t get past the kernel compilation step. I believe that this is due to the instructions being six months old, which are like two and a half centuries in computer time. So I continued searching and found a post in a Japanese blog. Using my fluent Japanese Google Translator I could understand what was going on and could successfully reproduce the steps and get Xenomai up and running (big thanks to the author!). Here I’ll reproduce the steps. I’m assuming that you are on a computer running Ubuntu (like mine) and are familiar with the command line.

Getting the tools

Step 0: Get all the tools that will be needed (cross-compiler and dev libraries).

Building the Kernel

Step 1: First of all, make a directory to hold all of our development files. I’ll call mine bbb
Step 2: Get the Linux kernel for the BeagleBone and the Xenomai sources. This might take a while.
Step 3: Checkout kernel 3.8 version branch. Apply BeagleBone’s patches.
Note: In this step I revert to a specific commit because newer ones are known to cause problems.
Step 4: Get a firmware that the kernel config will need (I’m not sure whether this firmware is really needed).
Step 5: Copy the BeagleBone default config as the running config.
Step 6: Apply I-pipe patches to the BeagleBone kernel.
Step 7: Run the Xenomai prepare-kernel  script for the BeagleBone kernel.
Step 8: Configure the kernel to be built.
Under  CPU Power Management --->  CPU Frequency scaling, disable  [ ] CPU Frequency scaling . (Note: Don’t know if it’s better to leave it enabled, read the comments!)
Under  Real-time sub-system  ---> Drivers ---> Testing drivers, enable everything.
Step 9: Compile the kernel.
Note: I chose 16 to the -j  option, because my computer has 8 cores. Choose a value appropriate to your computer. I read somewhere that 2 times the number of cores is a good number.
Note: If there were errors in the compilation, the messages will probably be lost among all other output. To see them, simply run the command again.

Preparing an SD Card

Now let’s get an SD Card ready with the Angstrom distribution and our kernel. If you want to use this kernel with the distribution on the eMMC memory, just put it in the appropriate place.
Step 10: Download and copy the default Angstrom distribution to your SD Card. Replace /dev/sdX  with the path to your SD Card.sudo fdisk -l  is your friend. Note: I used a SanDisk 4GB SD Card.
CAUTION: YOU WILL LOSE ALL YOUR PREVIOUS DATA ON THE DEVICE /dev/sdX !
Step 11: Mount the Angstrom partition. Copy kernel and kernel modules (thanks for your comment, Jurg Lehni!), Xenomai modules and source folder to that partition. Replace  /dev/sdX2  with your actual path to the partition.

Testing

Now put the SD card on the BeagleBone, boot it, ssh into it and test Xenomai.
Step 12: Configure the date and compile Xenomai
Note: an example for the date command would be  date -s "21 May 2014 13:25 GMT-3" 
Step 13: Load the testing driver
Step 14: Run some tests!
User-mode latency:
In-kernel Latency:
Poke around:
Change parameters:
Great, huh? Now go develop something real time =)
Reference: 
http://brunosmartins.info/xenomai-on-the-beaglebone-black-in-14-easy-steps/