Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/What is the cheapest way to lock the current thread to it's current core - PPC multi-core arch specific/List of Posts
Forum Topic - What is the cheapest way to lock the current thread to it's current core - PPC multi-core arch specific: (5 Items)
   
Update
Chip Bagwell
06/15/2011 11:11 AM
post86640
What is the cheapest way to lock the current thread to it's current core - PPC multi-core arch specific   
I know you can use ThreadCtl() to set the CPU runmask for a given thread, but that is a QNX kernel call and is fairly 
expensive.  Once the desired thread is running on a given CPU core, can if I disable external interrupts (EE bit in MSR)
 on that core to keep that thread from being migrated to a different core if it is pre-empted by a higher priority 
thread?  Also I believe I will have to ensure there are no QNX system calls within the scope of the disabling of 
interrupts to avoid Neutrino from re-enabling interrupts without my knowledge.  This seems much cheaper than issuing two
 ThreadCtl() calls, one to lock to the current core, one to unlock and allow the thread to run on all cores.

The thread in question is trying to utilize a memory-mapped region of on-chip registers.  Each core has it's own set of 
on-chip registers mapped into the process space.  Once the thread starts working with the registers, I need to make sure
 it does not migrate to a different thread until the critical section of code using those registers is complete.  Also 
the thread in question is rather high in priority relative to other threads in the process, but not the highest thread 
priority in the process.
Elena Laskavaia
06/15/2011 11:19 AM
post86641
Re: What is the cheapest way to lock the current thread to it's current core - PPC multi-core arch specific   
Considering you are doing it only ones I don't think expensive is applicable, you can do a simple check like

if (locked) {
  ThreadCtl(...)
  locked = true;
}

On 06/15/2011 11:11 AM, Chip Bagwell wrote:
> I know you can use ThreadCtl() to set the CPU runmask for a given thread, but that is a QNX kernel call and is fairly 
expensive.  Once the desired thread is running on a given CPU core, can if I disable external interrupts (EE bit in MSR)
 on that core to keep that thread from being migrated to a different core if it is pre-empted by a higher priority 
thread?  Also I believe I will have to ensure there are no QNX system calls within the scope of the disabling of 
interrupts to avoid Neutrino from re-enabling interrupts without my knowledge.  This seems much cheaper than issuing two
 ThreadCtl() calls, one to lock to the current core, one to unlock and allow the thread to run on all cores.
> 
> The thread in question is trying to utilize a memory-mapped region of on-chip registers.  Each core has it's own set 
of on-chip registers mapped into the process space.  Once the thread starts working with the registers, I need to make 
sure it does not migrate to a different thread until the critical section of code using those registers is complete.  
Also the thread in question is rather high in priority relative to other threads in the process, but not the highest 
thread priority in the process.
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post86640
>
Chip Bagwell
06/15/2011 11:26 AM
post86642
Re: What is the cheapest way to lock the current thread to it's current core - PPC multi-core arch specific   
I apologize for leaving out some important details.

This thread is a packet processing thread and would need to access these memory mapped registers every time a packet is 
received.  At high data rates I can envision needing to access the registers 300,000 to 700,000 times per second 
depending on the packet rate and it's arrival jitter.  Also I do want other threads to be able to use that core, just 
not when the packet processing thread is accessing the hardware registers.

So with that being said, would disabling interrupts on that core, prevent any other thread from being scheduled on that 
core?
David Sarrazin
06/15/2011 11:29 AM
post86643
RE: What is the cheapest way to lock the current thread to it's current core - PPC multi-core arch specific   
Chip,

Would it work to just create one thread per core, set their runmask to
that core, and then farm out the packets to them?  Just because one
thread is locked to a core doesn't mean other things can't use the core.
Otherwise you have to globally disable all interrupts on all cores
(since the kernel could perform scheduling work from a different core)
for the time that your thread is running, which is going to have
negative real-time implications.

David

> -----Original Message-----
> From: Chip Bagwell [mailto:community-noreply@qnx.com]
> Sent: June-15-11 11:26 AM
> To: ostech-core_os
> Subject: Re: What is the cheapest way to lock the current thread to
> it's current core - PPC multi-core arch specific
> 
> I apologize for leaving out some important details.
> 
> This thread is a packet processing thread and would need to access
> these memory mapped registers every time a packet is received.  At
high
> data rates I can envision needing to access the registers 300,000 to
> 700,000 times per second depending on the packet rate and it's arrival
> jitter.  Also I do want other threads to be able to use that core,
just
> not when the packet processing thread is accessing the hardware
> registers.
> 
> So with that being said, would disabling interrupts on that core,
> prevent any other thread from being scheduled on that core?
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post86642
Chip Bagwell
06/15/2011 12:33 PM
post86644
Re: RE: What is the cheapest way to lock the current thread to it's current core - PPC multi-core arch specific   
David,
I believe your solution will work, but it would require some rethinking of other areas of code.  Thanks for the help.
--Chip

Return


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