Hi Norman,
I agree with Udo's comment about needing to be more flexible about resource partitioning across v-cores. Of course you might use configuration scripts to help configure v-cores initially, but it is important to be able to dynamically adjust partitions at run-time according to workload needs. You should strive to separate the concerns of enabling NUMA and the policies behind NUMA.
I think that you can only evaluate the success of your NUMA capabilities with real applications. Hopefully we can help you there.
Daniel
On 03/18/2013 04:40 AM, Udo Steinberg wrote:
On Mon, 18 Mar 2013 11:49:40 +0100 Norman Feske (NF) wrote:
[Details snipped]
NF> What do you think? Would the vcore idea be worthwhile to explore? Those NF> of you experienced in the field of manycore NUMA systems, do you see NF> additional pitfalls? Or even better, does anyone has alternative ideas NF> to explore? Also, I am very interested in ways to validate work in this NF> domain. How can we measure our success?
There are also use cases where you don't want to partition. One example is a multi-core VM, where each virtual CPU could run on a different physical core and yet all of those virtual CPUs share the same memory.
Rather than going for an extreme design point, where virtually nothing is shared (e.g., Barrelfish), I think it would be better to provide an interface where the user has precise control over what is shared and what isn't.
I'd go for concurrent invocation of services first. Then you'll know what data structures you have contention on. And then you can decide whether you want that data replicated (read-mostly) or shared (frequently written).
IMHO, dealing with replicas, distributed protocols, consensus and all that is a lot harder than implementing a few locks or atomic ops on pieces of shared memory. Especially now that we have HLE and TSX coming really soon.
Cheers, Udo
Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main