| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] RE: Co-scheduling HVM domains...
Mark,
0) You are right, I was not subscribed to the list when I sent the first
email.
1) I've heard of something called stub domains that may do something
similar to case 1. I'm trying to get more info on it. Don't know if it
even works for Windows HVMs.
2) We'll have a lot more domain pairs than CPUs. They (the pairs) run
independent applications of each other so batching requests is not a
choice at this point. But we do know that the two pairs will
communicate (server-client app) and will use a shared memory construct
to pass the messages back (no IP connection, just a proprietary comm.
protocol using shared memory). There are latency issues involved in
getting to those packets so if we could guarantee that when the client
makes a request, the server will get it (almost) immediately, then we're
golden. So, I'm interested in tweaking the scheduling algorithm to
guarantee that the server can get on the CPU after the client runs.
Thank you
Roger R. Cruz
> I'm resending this to the list because I don't believe it made it
> through the first time.
If you're not subscribed there's a delay before somebody comes along and
manually allows your mail.
> I have a multi-processor, multi-core environment where I will be
running
> an application on one HVM domain A (Windows 2003) and another app in
> another HVM domain A' (Windows as well). There will be multiple
> instances of this pair combination. For performance reasons, I would
> like to find out if there is any way to control the scheduling of the
> paired domains, such that
>
>
>
> 1) if domain A is scheduled on a physical CPU 1, domain A' is
also
> scheduled at the same time on cpu 2. or
There's not a simple way of arranging this.
> 2) if domain A is scheduled on physical CPU, domain A' is the
next
> domain to be scheduled on the CPU, even if domain B was the next legal
> owner of the time slice.
If you can dedicate a CPU per domain pair then you can just pin each
domain
pair to a different CPU. This should approximate the behaviour you
want.
Even if you pin several pairs to a CPU it should bound the latency
somewhat... however...
What's you're application? If requests between your domains can be
batched up
somehow then I'd expect performance to be OK without special
configuration.
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no
pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home