Showing posts with label why. Show all posts
Showing posts with label why. 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.

Saturday, April 18, 2020

Linux: Why do we need an idle task?

There are two main reasons for having the idle task in the Linux kernel design:
  • Historical reason: In the older days, CPUs were not capable of idling in a lower power state, so they would constantly execute the no-operation (nop[1]) instruction. Now, with the advances in the CPU design, most processors will leverage a variant of the halt (HLT[2]) instruction that will allow them to go to a lower power mode.
  • Convenience: Instead of coding up and handling a special case for what to do when none of the processes are runnable i.e. the run queue is empty, we instead schedule the idle task, which is always runnable.

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

Saturday, January 4, 2020

Interesting Math Tutorials - Refreshers

Map of Mathematics

Sunday, October 13, 2019

Thought Experiment: Why not have multiple woofers for each channel

Ever wondered why there is a single subwoofer and multiple small speakers for higher frequencies?
Because the human hear can only distinguish the higher frequencies spatially. Why?
Because of the wavelength. The base (subwoofer) is the lower frequency sound which is usually a few HZ which would typically have a wavelength of the order of 10s of feet. Hence in this case, the two human ears which are placed less than a feet apart on our head cant differentiate between base sound  from different channels. Hence we only have one subwoofer for the base sounds and multiple smaller  speakers (5.1 or 2.1 stereo) for the higher frequency sounds.

Wednesday, August 28, 2019

Why Linux Kernel KASLR is not very effective

Recently, with more time on hand  I am reading about security in the Linux kernel. A common mode of attack on any program is using buffer overflow to implement return oriented programming (ROP) blobs. Return oriented programming is a mechanism of overwriting return addresses in a library to implement code blobs (or gadgets) that will perform the desired functionality.

Monday, August 26, 2019

Linux: Why to drop caches and how? Host or virtual machine

Repost of an old post

Excerpt from stackoverflow: "The reason to drop caches like this is for benchmarking disk performance, and is the only reason it exists. When running an I/O-intensive benchmark, you want to be sure that the various settings you try are all actually doing disk I/O, so Linux allows you to drop caches rather than do a full reboot."

How to drop caches on the host?

Tuesday, June 25, 2019

Linux: How does the kernel invoke the correct driver for the corresponding /dev file ops?

To answer this question, I am picking snippets of texts from different blogs that I read online.
"When devfs is not being used, adding a new driver to the system means assigning a major number to it. The assignment should be made at driver (module) initialization by calling the following function, defined in <linux/fs.h>:
int register_chrdev(unsigned int major, const char *name,
struct file_operations *fops);
The return value indicates success or failure of the operation. A negative return code signals an error; a 0 or positive return code reports successful completion. The major argument is the major number being requested, name is the name of your device, which will appear in /proc/devices, and fops is the pointer to an array of function pointers" [1]
Thus, this will result in the registration of the device driver with a major number with the kernel. 
"Once the driver has been registered in the kernel table, its operations are associated with the given major number. Whenever an operation is performed on a character device file associated with that major number, the kernel finds and invokes the proper function  from the  file_operations structure. For this reason, the pointer passed to register_chrdev should point to a global structure within the driver, not to one local to the module’s initialization function."