Re: Kernel code interrupted by Timer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <gjainroorkee@xxxxxxxxx> 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 <Jeff.Haran@xxxxxxxxxx> 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:gjainroorkee@xxxxxxxxx]
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 <Jeff.Haran@xxxxxxxxxx> 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:gjainroorkee@xxxxxxxxx]
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 <Jeff.Haran@xxxxxxxxxx> wrote:

I think you will find that this is a matter of kernel configuration. If kernel pre-emption is enabled at build time, then following the interrupt another process could get scheduled and it wouldn’t matter what interrupt went off. Typically some sort of explicit locking or RCU is used to protect critical sections in cases like this. On multi-core systems this should be done regardless of whether kernel pre-emption is enabled or not.

 

Jeff Haran

 

From: kernelnewbies-bounces@xxxxxxxxxxxxxxxxx [mailto:kernelnewbies-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Gaurav Jain
Sent: Friday, February 08, 2013 9:09 AM
To: Kernel Newbies
Subject: 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

 

 



 

--

Gaurav Jain

Associate Software Engineer

VxVM Escalations Team, SAMG

Symantec Software India Pvt. Ltd.

 



 

--

Gaurav Jain

Associate Software Engineer

VxVM Escalations Team, SAMG

Symantec Software India Pvt. Ltd.

 




--
Gaurav Jain
Associate Software Engineer
VxVM Escalations Team, SAMG
Symantec Software India Pvt. Ltd.





--
Gaurav Jain
Associate Software Engineer
VxVM Escalations Team, SAMG
Symantec Software India Pvt. Ltd.


_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux