Kernel code interrupted by Timer

[Gaurav Jain]

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 at gmail.com> 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 at citrix.com> 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 at 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 <Jeff.Haran at citrix.com> 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 at 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 <Jeff.Haran at citrix.com> 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 at kernelnewbies.org [mailto:
>> kernelnewbies-bounces at kernelnewbies.org] *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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130211/bdd3759f/attachment-0001.html