* Re: scheduler context
2013-04-17 10:05 scheduler context ratheesh kannoth
@ 2013-04-23 20:42 ` Henrik Austad
0 siblings, 0 replies; 2+ messages in thread
From: Henrik Austad @ 2013-04-23 20:42 UTC (permalink / raw)
To: ratheesh kannoth; +Cc: linux-kernel, linux-rt-users
[-- Attachment #1: Type: text/plain, Size: 4499 bytes --]
Hi Ratessh,
Before digging into your questions;
- LKML and linux-rt is probably not the best places to ask these kind of
questions. kernelnewbies is an excellent place to go to for quidance, and
you may get faster response there as well.
Furthermore; I recommend you to pick up a book about kernel development
(Linux Kernel Development by R. Love is a great place to start).
> I would like to understand on linux scheduler context. I have read a lot
> in websites and i could find contradictory statement. There are so many
> mailing list also ,but with less info. I would really appreciate if
> anybody could spend some time answering my question.
>
> 1. Which context scheduler run ? ( process context or interrupt context ).
um.. it does not run in interrupt-context. It will be in kernel-context,
either on return from interrupt or return to userspace from a syscall.
> 2. scheduler is the guy who picks up the next candidate to run. if
> it gets interrupted by hardirq, what will happen ?
On return to userspace, the kernel will check if TIF_NEED_RESCHED is set,
if so, it will invoke do_schedule() which will then see if there's a better
candidate to run.
> 3. if scheduler run in process context , how bottom half are scheduled ?
Bottom half can be several things
1) softirqs
2) tasklets
3) kernel threads
4) timers
Softirqs are run as soon as an interrupt handler has finished. These are
defined in a set of softirqs when you compile the kernel and are used for
interrupt-handlers that require a very fast response (network being a
candidate). Softirqs can run concurrently on any and all CPUs in the
system.
Tasklets are a simplification of softirqs, and it is pretty much (someone's
probably going to fry my nether regions for this simplification) a
work-queue for interrupt handlers. You currently have 2 versions, one
high-priorty queue and a normal one. They are handled by 2 corresponding
softirqs. Tasklets of the _same_ type can only run on a single CPU at a
time (but different tasklets can run concurrently).
Kernel threads are 'normal' threads, normal in the sense that they are
schedulable entities. Not normal in the sense that they do not have process
context (no *mm for instance).
Timers is a way to not only delay execution of some code, but delay it to a
specific point in time, say in 2 seconds. Once 2 secs has elapsed, the
timer will fire and the given function will be executed in the context of
the timer-softirq context.
> 4. In smp, schedule() function may be called simultaneously. How it
> is handled ?
You have one runqueue pr. cpu, each queue has a set of runnable tasks, it
will pick a task from that queue. One task cannot be placed in more than
one rq at a time.
> 5. When a bottom half is interrupted by hard irq, how softirq kernel
> thread saves the state and restart it later ?
...what i mean is , an
> hardirq came and its isr executed. bottom half enabled and bottom
> half gets scheduled . Before bottom half is completed , next irq
> came and it enables bottom half , and the new bottom half is
> scheduled ....So here , what will happen to old bottom half , will it
> again
> run later ?
So your question is "what happens to my system if a faulty piece of
hardware generates a flood of interrupts?"?
Meet: ksoftirqd
let me try to explain:
The moment you get a hard interrupt, the CPU will vector to the appropriate
handler, ack the interrupt and do whatever need doing right then. Once
done, it will _raise_the_softirq_ and return. The kernel will then start
processing the softirqs that need attention.
What happens here is:
- disable local interrupt
- get a list of softirqs that needs to be processed
- clear the list of pending softirqs
- renable interrupts
- process softirqs
Once this is done, it will check to see if there's any _new_ softirqs that
needs to be handled. If so, it will jump to the start and go through the
list one more time.
It will continue to do this for a pre-defined number of times
(MAX_SOFTIRQ_RESTART - which is 10) before prodding ksoftirqd to handle it.
So, to connect this to your question - if you get an excessive amount of
interrupts whilst in the middle of softirq processing, all you get is a set
of raised softirqs which will cause __do_softirq() to loop 10 times before
offloading the work to ksoftirqd.
--
Henrik Austad
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread