Re: Kernel code interrupted by Timer
Well, my bad. I was wrong there. Your example was correct. Even in a multi-kernel like Barrelfish, each core manages only its own share of memory. RAM is explicitly partitioned between cores running on each kernel and any data structures that need to be shared across cores have to be replicated in each of the memory partitions and consistency maintained through IPC. ~Gaurav On Fri, Feb 8, 2013 at 10:29 PM, Gaurav Jain wrote: > I guess you misinterpreted me... A multi-kernel like Barrelfish would have > separate kernel images running on different cores, but each of the > core/kernel would be able to address the *entire* physical memory > (including any memory-mapped devices). Hence, the database would still be > addressable/reachable from all cores. Traditional locking mechanisms to > protect the database (like in a single-kernel Linux) would be good here, > too. OR, like in Barrelfish, we could have explicit inter-core > communication messages to implement synchronization/consistency. > > ~ Gaurav > > > On Fri, Feb 8, 2013 at 9:34 PM, Jeff Haran wrote: > >> Well, for instance what we do. We maintain a big database of cell phone >> user IP addresses and other info in a kernel module running on a 24 core >> X86-64 system. All 24 cores can and do access that data. If each core had >> access to only a single partition of memory, then that DB would have to be >> spread across the various partitions and if the one core that could access >> a specific cell phone user’s info was busy while others were idle, access >> to that user’s would be delayed. The application is quite performance >> sensitive so having the ability for all cores to operate on all data makes >> for better performance. >> >> ** ** >> >> Jeff >> >> ** ** >> >> *From:* Gaurav Jain [mailto:gjainroor...@gmail.com] >> *Sent:* Friday, February 08, 2013 11:54 AM >> >> *To:* Jeff Haran >> *Subject:* Re: Kernel code interrupted by Timer >> >> ** ** >> >> "you can solve problems that can’t be easily solved if all the data is >> partitioned by CPU core." >> >> ** ** >> >> Can you please give an example or two of the aforementioned problems? I >> can think of efficient scheduling - a single kernel knowing what >> cores/processors are idle would help make better decisions without the >> overhead of message passing in separate kernels on separate cores. >> >> ** ** >> >> ~Gaurav >> >> ** ** >> >> On Fri, Feb 8, 2013 at 8:16 PM, Jeff Haran wrote: >> >> >> I did not write Linux, so just guessing here. I don’t think the issue is >> so much kernel images as shared access to kernel data. The synchronization >> primitives in the kernel (spin locks, read-write locks, RCU, etc) are there >> to protect data from being corrupted during concurrent access, not code. I >> am not familiar with barrelfish but I think most modern OSes, for instance >> the various BSD derivatives, work like this. I have no recent experience >> with it, but I’d bet Windows does the same thing. If you can run multiple >> cores on the same data safely by providing proper locking, you can solve >> problems that can’t be easily solved if all the data is partitioned by CPU >> core. >> >> >> >> Getting the locking right though can be a challenge, which is of course >> good for software engineer job security. 8^) >> >> >> >> Jeff >> >> >> >> *From:* Gaurav Jain [mailto:gjainroor...@gmail.com] >> *Sent:* Friday, February 08, 2013 11:03 AM >> *To:* Jeff Haran >> *Subject:* Re: Kernel code interrupted by Timer >> >> >> >> "On multi-core systems this should be done regardless of whether kernel >> pre-emption is enabled or not" >> >> >> >> -- Do you know why such a design decision was made - That a single kernel >> image should manage all the cores! I have worked on Barrelfish ( >> http://www.barrelfish.org/) a bit, and it boots a separate kernel on >> each of the cores. To me that appears to be the more intuitive approach. >> What advantages do we get by having a single kernel image on all cores? Is >> the convenience of being in the same address space (the single kernel's) at >> all cores at all times, the only/major reason? >> >> >> >> ~Gaurav >> >> >> >> On Fri, Feb 8, 2013 at 7:51 PM, Jeff Haran wrote: >> >> >> I think you will find that this is a matter of k
Re: Kernel code interrupted by Timer
On Sun, 2013-02-10 at 00:47 +0800, Peter Teoh wrote: > > > On Sun, Feb 10, 2013 at 12:22 AM, Frederic Weisbecker > wrote: > 2013/2/9 Peter Teoh : > > A search in the entire subtree of arch/x86/ and including > all its > > subdirectories, (for 3.2.0 kernel) return only TWO result > where > > preempt_schedule_irq is called: kernel/entry_64.S and > kernel/entry_32.S. > > And the called is in fact resume_kernel(), ie, it is NOT > called from timer > > interrupt, but from wakeup context of the CPU, and is only > executed ONCE > > upon waking up from hibernation. > > > > for example, calling from here: > > > > https://lkml.org/lkml/2012/5/2/298 > > > > so definitely this preempt_schedule_irq() calling from irq > mode is rare - at > > least for x86. > > > The name "resume_kernel" can indeed sound like something that > is > called on hibernation resume. It's actually not related at > all. It's a > piece of code that is called at the end of every irq and > exception > when the interrupted code was running in the kernel. If the > interrupted code was running in userspace, we jump to > resume_userspace. > > well, i guessed u must be the expert here, i have yet to really digest > all these...:-). thanks for the explanation. In the kernel folder do this: git log --author="Frederic Weisbecker" > > > -- > Regards, > Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
On Sun, Feb 10, 2013 at 12:22 AM, Frederic Weisbecker wrote: > 2013/2/9 Peter Teoh : > > A search in the entire subtree of arch/x86/ and including all its > > subdirectories, (for 3.2.0 kernel) return only TWO result where > > preempt_schedule_irq is called: kernel/entry_64.S and > kernel/entry_32.S. > > And the called is in fact resume_kernel(), ie, it is NOT called from > timer > > interrupt, but from wakeup context of the CPU, and is only executed ONCE > > upon waking up from hibernation. > > > > for example, calling from here: > > > > https://lkml.org/lkml/2012/5/2/298 > > > > so definitely this preempt_schedule_irq() calling from irq mode is rare > - at > > least for x86. > > The name "resume_kernel" can indeed sound like something that is > called on hibernation resume. It's actually not related at all. It's a > piece of code that is called at the end of every irq and exception > when the interrupted code was running in the kernel. If the > interrupted code was running in userspace, we jump to > resume_userspace. > well, i guessed u must be the expert here, i have yet to really digest all these...:-). thanks for the explanation. -- Regards, Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
2013/2/9 anish kumar :
> Thanks Frederic.
> On Sat, 2013-02-09 at 08:44 +0100, Frederic Weisbecker wrote:
>> In the case you have CONFIG_PREEMPT and it's the turn for some other
>> task to be scheduled, the function preempt_schedule_irq() is called
>> right before the irq return to the interrupted code. If the irq
>> interrupted preemptible code (code that was not under a
>> preempt_disable() section) then the scheduler may well schedule
>> another task.
> However if the code is under preempt_disable() when irq happened then it
> won't choose any other task and will come back immediately to the task
> which was preempted by the irq handler.
Right.
> I think what you are referring is below code:
>
> __irq_svc:
> svc_entry
> irq_handler
>
> #ifdef CONFIG_PREEMPT
> get_thread_info tsk
> ldr r8, [tsk, #TI_PREEMPT] @ get preempt count
> ldr r0, [tsk, #TI_FLAGS]@ get flags
> teq r8, #0 @ if preempt count != 0
> movne r0, #0 @ force flags to 0
> tst r0, #_TIF_NEED_RESCHED
> blnesvc_preempt
> #endif
>
> #ifdef CONFIG_PREEMPT
> svc_preempt:
> mov r8, lr
> 1: bl preempt_schedule_irq@ irq en/disable is done
> inside
> ldr r0, [tsk, #TI_FLAGS]@ get new tasks TI_FLAGS
> tst r0, #_TIF_NEED_RESCHED
> moveq pc, r8 @ go again
> b 1b
> #endif
>
>
> /*
> * this is the entry point to schedule() from kernel preemption
> * off of irq context.
> * Note, that this is called and return with irqs disabled. This will
> * protect us against recursive calling from irq.
> */
> asmlinkage void __sched preempt_schedule_irq(void)
> {
> struct thread_info *ti = current_thread_info();
>
> /* Catch callers which need to be fixed */
> BUG_ON(ti->preempt_count || !irqs_disabled());
>
> user_exit();
> do {
> add_preempt_count(PREEMPT_ACTIVE);
> local_irq_enable();
> __schedule();
> local_irq_disable();
> sub_preempt_count(PREEMPT_ACTIVE);
>
> /*
> * Check again in case we missed a preemption
> opportunity
> * between schedule and now.
> */
> barrier();
> } while (need_resched());
> }
>
>>
>> It may indeed sound suprising that we schedule from an interrupt but
> It is really *surprising* that we do scheduling from interrupt context.
> Doesn't Do's and Don't of scheduling from interrupt context apply here?
Yeah we typically don't want to be able to schedule from an interrupt
for a lot of reasons: the issuing device need to be informed quickly
that we are servicing the irq, sometimes the irq runs code that need
to be fast, the irq code assumes that it can't be itself interrupted
or preempted, etc... So for simplicity, it's simply not allowed.
But it doesn't apply here because the interrupt has been serviced and
we are about to resume to the interrupted code. From the logical
kernel point of view we have exited the irq (we have called
irq_exit()). So we can just re-enable the interrupts and schedule
another task. When we'll later schedule back the previous task that
called preempt_schedule_irq(), it will simply exit the irq and resume
to the interrupted code.
>> it's actually fine. Later on, the scheduler restores the previous task
>> to the middle of preempt_schedule_irq() and the irq completes its
> Sorry didn't understand this sentence i.e. "scheduler restores the
> previous task to the middle of preempt_schedule_irq()".
Yeah when we schedule another task we do a context switch. When the
previous task is rescheduled later it will resume from that context
switch point. Which is in the middle of schedule(), in the switch_to()
function.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
2013/2/9 Peter Teoh : > A search in the entire subtree of arch/x86/ and including all its > subdirectories, (for 3.2.0 kernel) return only TWO result where > preempt_schedule_irq is called: kernel/entry_64.S and kernel/entry_32.S. > And the called is in fact resume_kernel(), ie, it is NOT called from timer > interrupt, but from wakeup context of the CPU, and is only executed ONCE > upon waking up from hibernation. > > for example, calling from here: > > https://lkml.org/lkml/2012/5/2/298 > > so definitely this preempt_schedule_irq() calling from irq mode is rare - at > least for x86. The name "resume_kernel" can indeed sound like something that is called on hibernation resume. It's actually not related at all. It's a piece of code that is called at the end of every irq and exception when the interrupted code was running in the kernel. If the interrupted code was running in userspace, we jump to resume_userspace. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
On Sat, Feb 9, 2013 at 8:07 PM, anish kumar wrote:
> Thanks Frederic.
> On Sat, 2013-02-09 at 08:44 +0100, Frederic Weisbecker wrote:
> > 2013/2/8 Gaurav Jain :
> > > What happens if the kernel executing in some process context (let's say
> > > executing a time-consuming syscall) gets interrupted by the Timer -
> which is
> > > apparently allowed in 2.6 onwards kernels.
> > >
> > > My understanding is that once the interrupt handler is done executing,
> we
> > > should switch back to where the kernel code was executing.
> >
> > Exactly. At the end of the interrupt, the state of the processor
> > (register values) as it was before being interrupted is restored.
> >
> > > Specifically, the
> > > interrupt handler for the Timer interrupt should not schedule some
> other
> > > task since that might leave kernel data in an inconsistent state -
> kernel
> > > didn't finish doing whatever it was doing when interrupted.
> > >
> > > So, does the Timer interrupt handler include such a policy for the
> above
> > > case?
> >
> > In the case you have CONFIG_PREEMPT and it's the turn for some other
> > task to be scheduled, the function preempt_schedule_irq() is called
> > right before the irq return to the interrupted code. If the irq
> > interrupted preemptible code (code that was not under a
> > preempt_disable() section) then the scheduler may well schedule
> > another task.
> However if the code is under preempt_disable() when irq happened then it
> won't choose any other task and will come back immediately to the task
> which was preempted by the irq handler.
>
> I think what you are referring is below code:
>
> __irq_svc:
> svc_entry
> irq_handler
>
> #ifdef CONFIG_PREEMPT
> get_thread_info tsk
> ldr r8, [tsk, #TI_PREEMPT] @ get preempt count
> ldr r0, [tsk, #TI_FLAGS]@ get flags
> teq r8, #0 @ if preempt count != 0
> movne r0, #0 @ force flags to 0
> tst r0, #_TIF_NEED_RESCHED
> blnesvc_preempt
> #endif
>
> #ifdef CONFIG_PREEMPT
> svc_preempt:
> mov r8, lr
> 1: bl preempt_schedule_irq@ irq en/disable is done
> inside
> ldr r0, [tsk, #TI_FLAGS]@ get new tasks TI_FLAGS
> tst r0, #_TIF_NEED_RESCHED
> moveq pc, r8 @ go again
> b 1b
> #endif
>
>
> /*
> * this is the entry point to schedule() from kernel preemption
> * off of irq context.
> * Note, that this is called and return with irqs disabled. This will
> * protect us against recursive calling from irq.
> */
> asmlinkage void __sched preempt_schedule_irq(void)
> {
> struct thread_info *ti = current_thread_info();
>
> /* Catch callers which need to be fixed */
> BUG_ON(ti->preempt_count || !irqs_disabled());
>
> user_exit();
> do {
> add_preempt_count(PREEMPT_ACTIVE);
> local_irq_enable();
> __schedule();
> local_irq_disable();
> sub_preempt_count(PREEMPT_ACTIVE);
>
> /*
> * Check again in case we missed a preemption
> opportunity
> * between schedule and now.
> */
> barrier();
> } while (need_resched());
> }
>
> >
> > It may indeed sound suprising that we schedule from an interrupt but
> It is really *surprising* that we do scheduling from interrupt context.
> Doesn't Do's and Don't of scheduling from interrupt context apply here?
>
A search in the entire subtree of arch/x86/ and including all its
subdirectories, (for 3.2.0 kernel) return only TWO result where
preempt_schedule_irq is called: kernel/entry_64.S and kernel/entry_32.S.
And the called is in fact resume_kernel(), ie, it is NOT called from
timer interrupt, but from wakeup context of the CPU, and is only executed
ONCE upon waking up from hibernation.
for example, calling from here:
https://lkml.org/lkml/2012/5/2/298
so definitely this preempt_schedule_irq() calling from irq mode is rare -
at least for x86.
but the code u have shown above is for ARM, i tried to understand it, but
could not comment muchexcept that it CONFIG_PREEMPT is still very
popular: out of 121 of different ARM boards, about 46 still need it to be
"y".
>
> So how does the regular call to schedule() occur when task(process) time
> slice is over?
> > it's actually fine. Later on, the scheduler restores the previous task
> > to the middle of preempt_schedule_irq() and the irq completes its
> Sorry didn't understand this sentence i.e. "scheduler restores the
> previous task to the middle of preempt_schedule_irq()".
> > return to what it interrupted. The state of the processor prior to the
> > interrupt is stored on the task stack. So we can restore that anytime.
> > Note if the irq interrupted userspace, it can do about the same th
Re: Kernel code interrupted by Timer
Thanks Frederic.
On Sat, 2013-02-09 at 08:44 +0100, Frederic Weisbecker wrote:
> 2013/2/8 Gaurav Jain :
> > What happens if the kernel executing in some process context (let's say
> > executing a time-consuming syscall) gets interrupted by the Timer - which is
> > apparently allowed in 2.6 onwards kernels.
> >
> > My understanding is that once the interrupt handler is done executing, we
> > should switch back to where the kernel code was executing.
>
> Exactly. At the end of the interrupt, the state of the processor
> (register values) as it was before being interrupted is restored.
>
> > Specifically, the
> > interrupt handler for the Timer interrupt should not schedule some other
> > task since that might leave kernel data in an inconsistent state - kernel
> > didn't finish doing whatever it was doing when interrupted.
> >
> > So, does the Timer interrupt handler include such a policy for the above
> > case?
>
> In the case you have CONFIG_PREEMPT and it's the turn for some other
> task to be scheduled, the function preempt_schedule_irq() is called
> right before the irq return to the interrupted code. If the irq
> interrupted preemptible code (code that was not under a
> preempt_disable() section) then the scheduler may well schedule
> another task.
However if the code is under preempt_disable() when irq happened then it
won't choose any other task and will come back immediately to the task
which was preempted by the irq handler.
I think what you are referring is below code:
__irq_svc:
svc_entry
irq_handler
#ifdef CONFIG_PREEMPT
get_thread_info tsk
ldr r8, [tsk, #TI_PREEMPT] @ get preempt count
ldr r0, [tsk, #TI_FLAGS]@ get flags
teq r8, #0 @ if preempt count != 0
movne r0, #0 @ force flags to 0
tst r0, #_TIF_NEED_RESCHED
blnesvc_preempt
#endif
#ifdef CONFIG_PREEMPT
svc_preempt:
mov r8, lr
1: bl preempt_schedule_irq@ irq en/disable is done
inside
ldr r0, [tsk, #TI_FLAGS]@ get new tasks TI_FLAGS
tst r0, #_TIF_NEED_RESCHED
moveq pc, r8 @ go again
b 1b
#endif
/*
* this is the entry point to schedule() from kernel preemption
* off of irq context.
* Note, that this is called and return with irqs disabled. This will
* protect us against recursive calling from irq.
*/
asmlinkage void __sched preempt_schedule_irq(void)
{
struct thread_info *ti = current_thread_info();
/* Catch callers which need to be fixed */
BUG_ON(ti->preempt_count || !irqs_disabled());
user_exit();
do {
add_preempt_count(PREEMPT_ACTIVE);
local_irq_enable();
__schedule();
local_irq_disable();
sub_preempt_count(PREEMPT_ACTIVE);
/*
* Check again in case we missed a preemption
opportunity
* between schedule and now.
*/
barrier();
} while (need_resched());
}
>
> It may indeed sound suprising that we schedule from an interrupt but
It is really *surprising* that we do scheduling from interrupt context.
Doesn't Do's and Don't of scheduling from interrupt context apply here?
So how does the regular call to schedule() occur when task(process) time
slice is over?
> it's actually fine. Later on, the scheduler restores the previous task
> to the middle of preempt_schedule_irq() and the irq completes its
Sorry didn't understand this sentence i.e. "scheduler restores the
previous task to the middle of preempt_schedule_irq()".
> return to what it interrupted. The state of the processor prior to the
> interrupt is stored on the task stack. So we can restore that anytime.
> Note if the irq interrupted userspace, it can do about the same thing,
> except it calls schedule() directly instead of preempt_schedule_irq().
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
On Sat, Feb 9, 2013 at 4:20 PM, Peter Teoh wrote: > > > On Sat, Feb 9, 2013 at 3:51 PM, anish kumar > wrote: > >> On Sat, 2013-02-09 at 14:57 +0800, Peter Teoh wrote: >> > >> > >> > On Sat, Feb 9, 2013 at 1:47 PM, anish kumar >> > . >> > Timer interrupts is supposed to cause scheduling and scheduler >> > may or >> > may not pick up your last process(we always use the term >> > "task" in >> > kernel space) after handling timer interrupt. >> > > >> > >> > >> > >> > Sorry if I may disagree, correct me if wrong. Timer interrupt and >> > scheduler is two different thing. I just counted in the "drivers" >> > subdirectory, there are at least more than 200 places where >> > "setup_timer()" is called, and these have nothing to do with >> > scheduling. For eg, heartbeat operation etc. Not sure I >> > misunderstood something? >> Have a look at kernel/timer.c and kernel/hrtimer.c. >> There are many sched() calls in these files.This will invoke scheduler. >> > >> > > kernel/timer.c and kernel/hrtimer.c are implementing the logic outside of > timer interrupt context, ie, it is NOT executed in timer interrupt context, > but in bottom half context. the real timer interrupt context is done in > arch-specific branch: arch/x86/kernel/tsc.c, for example, and the entire > tsc.c has no scheduling concept in it. the entire file tsc.c in fact is > handling all the hardware-specific stuff - in the top-half context. > one mistake here: kernel/timer.c is running in bottom half interrupt context, which is still in interrupt context/mode.but as I glanced through the entire kernel/timer.c, there is no task scheduling called anywhere in this file. it is doing timer scheduling in fact. whereas the context switching we were discussing, that necessitate consistent state maintenance, is done in task scheduling (inside kernel/sched.c). of course sometimes timer interrupt will trigger task scheduling logic sometime, but it is not always..not sure if my statement is correct? (no time to search the source, please pardon me). > > in linux kernel scheduling is done in two ways: voluntary and involuntary > scheduling. involuntary scheduling means it is triggered by timer > interrupt. but voluntary scheduling (which is only recently introduced > into kernel for performance reasons) drastically improve the latency > numbers.voluntary scheduling is NOT triggered by timer, but ANYONE who > want to give up the CPU can call sched_cpu() to do a rescheduling. > > hope i am not wrong. > > >> > >> > -- >> > Regards, >> > Peter Teoh >> >> >> > > > -- > Regards, > Peter Teoh -- Regards, Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
On Sat, Feb 9, 2013 at 3:51 PM, anish kumar wrote: > On Sat, 2013-02-09 at 14:57 +0800, Peter Teoh wrote: > > > > > > On Sat, Feb 9, 2013 at 1:47 PM, anish kumar > > . > > Timer interrupts is supposed to cause scheduling and scheduler > > may or > > may not pick up your last process(we always use the term > > "task" in > > kernel space) after handling timer interrupt. > > > > > > > > > > > Sorry if I may disagree, correct me if wrong. Timer interrupt and > > scheduler is two different thing. I just counted in the "drivers" > > subdirectory, there are at least more than 200 places where > > "setup_timer()" is called, and these have nothing to do with > > scheduling. For eg, heartbeat operation etc. Not sure I > > misunderstood something? > Have a look at kernel/timer.c and kernel/hrtimer.c. > There are many sched() calls in these files.This will invoke scheduler. > > > kernel/timer.c and kernel/hrtimer.c are implementing the logic outside of timer interrupt context, ie, it is NOT executed in timer interrupt context, but in bottom half context. the real timer interrupt context is done in arch-specific branch: arch/x86/kernel/tsc.c, for example, and the entire tsc.c has no scheduling concept in it. the entire file tsc.c in fact is handling all the hardware-specific stuff - in the top-half context. in linux kernel scheduling is done in two ways: voluntary and involuntary scheduling. involuntary scheduling means it is triggered by timer interrupt. but voluntary scheduling (which is only recently introduced into kernel for performance reasons) drastically improve the latency numbers.voluntary scheduling is NOT triggered by timer, but ANYONE who want to give up the CPU can call sched_cpu() to do a rescheduling. hope i am not wrong. > > > > -- > > Regards, > > Peter Teoh > > > -- Regards, Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
On Sat, 2013-02-09 at 14:57 +0800, Peter Teoh wrote: > > > On Sat, Feb 9, 2013 at 1:47 PM, anish kumar > . > Timer interrupts is supposed to cause scheduling and scheduler > may or > may not pick up your last process(we always use the term > "task" in > kernel space) after handling timer interrupt. > > > > > > Sorry if I may disagree, correct me if wrong. Timer interrupt and > scheduler is two different thing. I just counted in the "drivers" > subdirectory, there are at least more than 200 places where > "setup_timer()" is called, and these have nothing to do with > scheduling. For eg, heartbeat operation etc. Not sure I > misunderstood something? Have a look at kernel/timer.c and kernel/hrtimer.c. There are many sched() calls in these files.This will invoke scheduler. > > > -- > Regards, > Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
2013/2/8 Gaurav Jain : > What happens if the kernel executing in some process context (let's say > executing a time-consuming syscall) gets interrupted by the Timer - which is > apparently allowed in 2.6 onwards kernels. > > My understanding is that once the interrupt handler is done executing, we > should switch back to where the kernel code was executing. Exactly. At the end of the interrupt, the state of the processor (register values) as it was before being interrupted is restored. > Specifically, the > interrupt handler for the Timer interrupt should not schedule some other > task since that might leave kernel data in an inconsistent state - kernel > didn't finish doing whatever it was doing when interrupted. > > So, does the Timer interrupt handler include such a policy for the above > case? In the case you have CONFIG_PREEMPT and it's the turn for some other task to be scheduled, the function preempt_schedule_irq() is called right before the irq return to the interrupted code. If the irq interrupted preemptible code (code that was not under a preempt_disable() section) then the scheduler may well schedule another task. It may indeed sound suprising that we schedule from an interrupt but it's actually fine. Later on, the scheduler restores the previous task to the middle of preempt_schedule_irq() and the irq completes its return to what it interrupted. The state of the processor prior to the interrupt is stored on the task stack. So we can restore that anytime. Note if the irq interrupted userspace, it can do about the same thing, except it calls schedule() directly instead of preempt_schedule_irq(). ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
On Sat, Feb 9, 2013 at 1:47 PM, anish kumar . > > Timer interrupts is supposed to cause scheduling and scheduler may or > may not pick up your last process(we always use the term "task" in > kernel space) after handling timer interrupt. > > > Sorry if I may disagree, correct me if wrong. Timer interrupt and scheduler is two different thing. I just counted in the "drivers" subdirectory, there are at least more than 200 places where "setup_timer()" is called, and these have nothing to do with scheduling. For eg, heartbeat operation etc. Not sure I misunderstood something? -- Regards, Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
On Fri, 2013-02-08 at 18:08 +0100, Gaurav Jain wrote: > What happens if the kernel executing in some process context (let's > say executing a time-consuming syscall) gets interrupted by the Timer > - which is apparently allowed in 2.6 onwards kernels. > > > My understanding is that once the interrupt handler is done executing, > we should switch back to where the kernel code was executing. *Should* doesn't mean immediately. > Specifically, the interrupt handler for the Timer interrupt should > not schedule some other task since that might leave kernel data in an > inconsistent state - kernel didn't finish doing whatever it was doing > when interrupted. Timer interrupts is supposed to cause scheduling and scheduler may or may not pick up your last process(we always use the term "task" in kernel space) after handling timer interrupt. > > > So, does the Timer interrupt handler include such a policy for the > above case? what do you mean? > > > > -- > Gaurav Jain > > > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
On Sat, Feb 9, 2013 at 8:08 AM, Peter Teoh wrote: > > > On Sat, Feb 9, 2013 at 1:08 AM, Gaurav Jain wrote: > >> What happens if the kernel executing in some process context (let's say >> executing a time-consuming syscall) gets interrupted by the Timer - which >> is apparently allowed in 2.6 onwards kernels. >> >> My understanding is that once the interrupt handler is done executing, we >> should switch back to where the kernel code was executing. Specifically, >> the interrupt handler for the Timer interrupt should not schedule some >> other task since that might leave kernel data in an inconsistent state - >> kernel didn't finish doing whatever it was doing when interrupted. >> > > at the microscopic level, every stream of assembly instructions can always > be broken up and intercepted by interrupt, and possibly switched into > another stream of assembly instruction or logic, the maintenance of state > "consistency" is done via context switching. > context switching is done at software level, and i am not if there is difference between process context switch or thread/task level context switching, but hardware only guarantee register context switch - and not sure if it covers all the floating point (SSE) registers too (unlikely, performance overheads)so.."consistency" is really how you write your software. and u also have multiple switching (by different CPU) all taking place independently all the time, writing into the same piece of RAM. I also know that nvidia GPU does not clean up its memory/state when switching from one process to another process, but that is beyond the control of hardware switching logic of the CPU anyway. > >> So, does the Timer interrupt handler include such a policy for the above >> case? >> >> -- >> Gaurav Jain >> >> >> >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> > > > -- > Regards, > Peter Teoh -- Regards, Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel code interrupted by Timer
On Sat, Feb 9, 2013 at 1:08 AM, Gaurav Jain wrote: > What happens if the kernel executing in some process context (let's say > executing a time-consuming syscall) gets interrupted by the Timer - which > is apparently allowed in 2.6 onwards kernels. > > My understanding is that once the interrupt handler is done executing, we > should switch back to where the kernel code was executing. Specifically, > the interrupt handler for the Timer interrupt should not schedule some > other task since that might leave kernel data in an inconsistent state - > kernel didn't finish doing whatever it was doing when interrupted. > at the microscopic level, every stream of assembly instructions can always be broken up and intercepted by interrupt, and possibly switched into another stream of assembly instruction or logic, the maintenance of state "consistency" is done via context switching. > So, does the Timer interrupt handler include such a policy for the above > case? > > -- > Gaurav Jain > > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- Regards, Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Kernel code interrupted by Timer
What happens if the kernel executing in some process context (let's say executing a time-consuming syscall) gets interrupted by the Timer - which is apparently allowed in 2.6 onwards kernels. My understanding is that once the interrupt handler is done executing, we should switch back to where the kernel code was executing. Specifically, the interrupt handler for the Timer interrupt should not schedule some other task since that might leave kernel data in an inconsistent state - kernel didn't finish doing whatever it was doing when interrupted. So, does the Timer interrupt handler include such a policy for the above case? -- Gaurav Jain ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
