Re: scheduler context

[Henrik Austad]

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: signature.asc
Description: Digital signature