Showing posts with label memory. Show all posts
Showing posts with label memory. Show all posts

Thursday, June 4, 2020

Linux: Why is skb recycling done

Why is this done?
* Saves the cost of allocating and de-allocating memory repeatedly.
* Savings are significant because this is a very frequent operation (usually skb alloc and de-alloc is done on a per-packet basis).

Recent changes to SKB recycling:

"- Make skb recycling available to all drivers, without needing driver
  modifications.

- Allow recycling skbuffs in more cases, by having the recycle check
  in __kfree_skb() instead of in the ethernet driver transmit
  completion routine.  This also allows for example recycling locally
  destined skbuffs, instead of only recycling forwarded skbuffs as
  the transmit completion-time check does.

- Allow more consumers of skbuffs in the system use recycled skbuffs,
  and not just the rx refill process in the driver.

Sunday, January 5, 2020

Linux: Why is the buddy system needed? - To prevent fragmentation

The buddy system is a mechanism for page management in Linux. It is needed to make sure that the free memory does not get fragmented and unusable. For an overview of the buddy system including a simple example of how it works, see this page [2]. From the same page, "In comparison to other simpler techniques such as dynamic allocation, the buddy memory system has little external fragmentation, and allows for compaction of memory with little overhead. The buddy method of freeing memory is fast, with the maximal number of compactions required equal to log2(highest order). Typically the buddy memory allocation system is implemented with the use of a binary tree to represent used or unused split memory blocks. The "buddy" of each block can be found with an exclusive OR of the block's address and the block's size."

An alternative to the buddy system would be to use the memory management unit (MMU) support to rewire or re-arrange blobs of free pages together to construct larger contiguous pages. However, this will not work for DMA systems which bypass the MMU. Also, modifying the virtual address on a continual basis would make the paging process slow.

Debugging on the buddy system can be done by printing the current stats. This is supported under the /proc/buddyinfo file. As described in the guide from centos.org, fragmentation issues can be debugged. A sample output from the same site is as shown below:
cat /proc/buddyinfo

Sunday, May 19, 2019

Linux: When to use kmalloc vs kmem_cache_alloc vs Vmalloc?

Read the quick comparison here: 
Linux Memory Management API Quick Primer  [Download PDF]
Gautam Bhanage | www.Bhanage.com | Pub2: GDB2019-001 June 2019

At a high level:
1. kmalloc for all generic memory allocation
2. kmem_cache_alloc for repeatetive structs that need allocations. These structures typically need to be accessed frequently (and are L1 & L2 cache aligned by the kernel).This is done much more efficiently through the slab allocator.
3. vmalloc() - allocates virtually contiguous memory. Not really useful from a linux kernel driver perspective.