kernel-deferred-work.txt
Deferring is a method by which you schedule a piece of work to be executed in the future.
It's a way to report an action later. Obviously, the kernel provides facilities to implement
such a mechanism; it allows you to defer functions, whatever their type, to be called and
executed later. There are three of them in the kernel, as outlined here:
• Softirqs: Executed in an atomic context
• Tasklets: Executed in an atomic context
• Workqueues: Executed in a process context
atomic context: https://inria.hal.science/hal-03032244/document#:~:text=Atomic%20context%20is%20an%20execution,%2Dcontext%20(SAC)%20bug.
Atomic context is an execution state of the Linux kernel, in which kernel code monopolizes a CPU core. In
this state, the Linux kernel may only perform operations that cannot sleep, as otherwise a system hang or
crash may occur.
https://stackoverflow.com/questions/3464700/why-spinlocks-are-used-in-interrupt-handlers#:~:text=Can%20we%20use%20the%20semaphore,to%20sleep%20in%20interrupt%20handlers.
Whats the problem with semaphore & mutex. And why spinlock needed ?
Can we use the semaphore or mutex in interrupt handlers. The answer is yes and no. you can use the up and unlock, but you can’t use down and lock, as these are blocking calls which put the process to sleep and we are not supposed to sleep in interrupt handlers.
Note that semaphore is not a systemV IPC techniques, its just a synchronization techniques. And there are three functions to acquires the semaphore.
down() : acquire the semaphore and put into un-interruptible state.
down_trylock() : try if lock is available, if lock is not available , don't sleep.
up() :- its useful for releasing the semaphore
So, what if we want to achieve the synchronization in interrupt handlers ? Use spinlocks.
What spinlocks will do ?
Spinlock is a lock which never yields.
Similar to mutex, it has two operations – lock and unlock.
If the lock is available, process will acquire it and will continue in the critical section and unlock it, once its done. This is similar to mutex. But, what if lock is not available ? Here, comes the interesting difference. With mutex, the process will sleep, until the lock is available. But,
in case of spinlock, it goes into the tight loop, where it continuously checks for a lock, until it becomes available
https://litux.nl/mirror/kerneldevelopment/0672327201/ch09lev1sec2.html
checkpatch.pl:
/home/n/Study/project/buildroot/beaglebone-project/kernelbuildscripts/KERNEL/scripts/checkpatch.pl -f binary-tree.c --no-tree --fix-inplace
-------------------
How modprobe works
modprobe command loads all required modules based on the output of
depmod -a /lib/moduesl/version/modules.dep
So run
depmod -a to update module dependencies
run modprobe <alias> to load the module
-------------------------------------------------------------------
Waitqueue
The kernel scheduler manages a list of tasks to run (tasks in a TASK_RUNNING state), known as a runqueue.
On the other hand, sleeping tasks, whether interruptible or not (in a TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE state), have their own queues, known as wait queues.
struct wait_queue_head {
spinlock_t lock;
struct list_head head;
};
A wait queue is nothing but a list (with sleeping processes in it waiting to be awakened) and a spinlock to protect access to this list.
Comments
Post a Comment