Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
When a timer interrupt happens, it cannot immediately call schedule() because, at that moment, it is still in an interrupt-handler context.
What it does, instead, is to set the NEEDS_RESCHEDULE flag. This flag is checked when we are otherwise ready to return to user mode.
Generally speaking, any interrupt-handler is divided into what is casually called the top half and the bottom half. (While these terms were literally used as the names of now-deprecated mechanisms in the kernel itself, the essential notion denoted by terms such as these, remains useful: interrupt processing occurs in two stages.) Conceptually, "the top half" is the immediate and very-brief response to the actual hardware signal, but almost all that we actually do at that time is to arrange for the "real" interrupt response to occur "soon." That work is done in "the bottom half."
For example, a timer-interrupt will cause the current process to be pre-empted "soon." It may cause task-queues, tasklets, or other deferred-execution units-of-work to become "runnable," so that they will occur "soon." An I/O interrupt's top-half handler will scoop status-information from the controller's registers, then schedule the bottom-half, which is where the consequences of the data-transfer that has just happened will be dealt with.
yea a scheduling slice is/can be larger than timer ticks so there is also p->counter
leading to p->need_resched
timeslice is dynamically calculated based on priorities i think and different people run ticks of different frequencies for various reasons.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.