Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/Kernel Lock times / Operations to avoid ?/List of Posts
Forum Topic - Kernel Lock times / Operations to avoid ?: (7 Items)
   
Update
Malte Mundt(deleted)
07/03/2009 8:58 AM
post33021
Kernel Lock times / Operations to avoid ?   
Hi,

I'm working with a customer who has very hard realtime requirements when it comes to interrupt latency and the absence 
of jitter when receiving interrupts.

I know our kernel is preemptible, but I believe that sometimes the kernel has to lock (disable) interrupts in order to 
do some things where it needs to be 'alone' and cannot be interrupted. Is this correct?

Which operations are having the longest lock periods on them? For example, I believe that creation and termination of 
processes can cause significant jitter in interrupt latency, so should be avoided in hard realtime situations. What 
other operations should be avoided?


- Malte
Sunil Kittur(deleted)
07/03/2009 9:12 AM
post33027
Re: Kernel Lock times / Operations to avoid ?   
The kernel lock affects thread scheduling latency - raw (ISR) interrupt latency
is not affected by the kernel lock at all, although the handling of sigevents
will be deferred until the locked kernel call exits the kernel.

The obvious places where the kernel lock can be held for some time are:
- process creation and termination
- thread creation and termination
- mapping/unmapping memory
- signal deliver to large numbers of processes (eg. big process groups)

	Sunil.

Malte Mundt wrote:
> Hi,
> 
> I'm working with a customer who has very hard realtime requirements when it comes to interrupt latency and the absence
 of jitter when receiving interrupts.
> 
> I know our kernel is preemptible, but I believe that sometimes the kernel has to lock (disable) interrupts in order to
 do some things where it needs to be 'alone' and cannot be interrupted. Is this correct?
> 
> Which operations are having the longest lock periods on them? For example, I believe that creation and termination of 
processes can cause significant jitter in interrupt latency, so should be avoided in hard realtime situations. What 
other operations should be avoided?
> 
> 
> - Malte
>  
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post33021
>
Malte Mundt(deleted)
07/06/2009 4:51 AM
post33143
Re: Kernel Lock times / Operations to avoid ?   
Thanks for the info. This sounds as if procnto never disables interrupts, can you confirm?


- Malte
Douglas Bailey
07/06/2009 9:30 AM
post33168
RE: Kernel Lock times / Operations to avoid ?   
No, that's not true.  We do disable interrupts for very short periods of time, as a mutual exclusion mechanism.  Plus 
some CPUs disable exceptions of all sorts (interrupts included) when they take an exception, and it takes a few dozen 
instructions before the kernel gets exceptions enabled again.

-----Original Message-----
From: Malte Mundt [mailto:community-noreply@qnx.com]
Sent: Mon 7/6/2009 4:51 AM
To: ostech-core_os
Subject: Re: Kernel Lock times / Operations to avoid ?
 
Thanks for the info. This sounds as if procnto never disables interrupts, can you confirm?


- Malte


_______________________________________________
OSTech
http://community.qnx.com/sf/go/post33143
Attachment: Text winmail.dat 2.71 KB
Malte Mundt(deleted)
07/15/2009 6:20 AM
post33795
Re: RE: Kernel Lock times / Operations to avoid ?   
Thanks Doug - are there certain kernel calls the customer should avoid in hard realtime situations, to not run into this
 Interrupt Lock situations?


- Malte
Douglas Bailey
07/15/2009 10:06 AM
post33830
Re: RE: Kernel Lock times / Operations to avoid ?   
All system calls have interrupts disabled for a very short time (a few
dozen instructions) during the transition into the kernel.  There are a
number of places in cpu-specific code where we disable interrupts,
typically while mucking around with TLBs or address spaces.
Instrumented kernels sometimes disable interrupts while storing events.
Aside from that, in common code, there are only a couple of places we
disable interrupts and those situations are typically only a few lines
of code -- on the same order as the transition-into-kernel code.

So, aside from avoiding the instrumented kernel (Colin?  Care to comment
on the effects of -instr variants on hard realtime systems?) I'd say
there's nothing specific to avoid.

Doug

On Wed, 2009-07-15 at 06:20 -0400, Malte Mundt wrote:
> Thanks Doug - are there certain kernel calls the customer should avoid in hard realtime situations, to not run into 
this Interrupt Lock situations?
> 
> 
> - Malte
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post33795
>
Malte Mundt(deleted)
07/15/2009 10:24 AM
post33834
Re: RE: Kernel Lock times / Operations to avoid ?   
Good info, thanks!


- Malte

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems