Genode Page-Fault Handling and IRQ architecture

Norman Feske norman.feske at ...1...
Thu Dec 20 15:05:55 CET 2012


Hi Daniel,

>> * To partition the physical memory, RAM sessions would need to carry
>>   affinity information with them - similar to how CPU sessions are
>>   already having priority information associated to them. Each RAM
>>   session would then use a different pool of physical memory.
> 
> Could I not use nested RM sessions/dataspaces to help with this?

I am not 100% convinced that nested RM sessions would be the best way to
go because you just want to tailor the allocation strategy of physical
memory. Whereas the on-demand paging facility of nested RM sessions will
remain unused, the overhead must be paid. But the general idea to
virtualize core's RAM session on top of core points into the right
direction. (similar to how the ACPI driver virtualizes core's IRQ
service to support IRQ remapping)

>> Maybe the sequence diagram was a bit misleading. It is displaying the
>> sequence for just one IRQ number. For each IRQ, there is a completely
>> different flow of control. I.e., there is one thread per IRQ session in
> core. The
>> processing of IRQs are not serialized at all. They are processed
> concurrently.

After checking back with Sebastian about this, I learned that currently,
base-foc does indeed have one central thread that dispatches IRQs coming
from the kernel to the various IRQ threads within core. Even though this
dispatcher thread is active for a brief period of time only, IRQs are
first delivered to always the same CPU, which you like to avoid.
Therefore, we should employ one thread per CPU or go for the
optimizations I outlined in my last email.

> Yes, I guess so - that is providing it makes sense for the general Genode
> distribution.  Also, this
> might be a stop-gap until we/you get some of the changes into Genode.

That sounds good to me.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth




More information about the users mailing list