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