| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-devel] Possibilities with Xen3 compared to IBM Power5 DLPAR
Hey Mark,
Thanks for your answers!
On 15.03.2007 4:18 "Mark Williamson" <mark.williamson@xxxxxxxxxxxx> wrote:
> Are we talking about Xen/PPC or Xen/x86 here?
Mainly I'm talking about the x86 platform - but the feature list should
apply to all platforms if possible :-)
Although the Power5 platform could offer more direct support in hardware...
I'm not sure if it where possible to use the hardware part of IBM's
hypervisor in xen.
> I think the credit scheduler supports at least some of this.
What exactly does that mean? :-)
Are you talking about the basic support so that one could step into these
features some day? I'm asking because I could not find any variables for the
config files to set an entitlement or so. At the moment I think the smallest
unit to assign processing power is per physical processor. But how can I
assign this more granular, e.g. only a half physical processor (0.5
entitlement) to 1 or x virtual processors? I'm also missing to have a
variable to weight important domU's with higher priority than some small and
unimportant domU's. At the moment each dom is equal to the others which
maybe is not what professionals would like to have...
> VCPU hotplug Just Works for XenLinux guests, I think. Memory resizing also
> works for XenLinux but it's worth noting that if you shrink a domain too
> aggressively Linux gets confused about where its memory is going and things
> start to break!
Quite clear that the domU has to be xen-aware in order to re-read the memory
allocaion table outside the domU space. And I was not really thinking a
fully virtualized guest esp. like Windows could ever do so :-)
> SMT is supported where the hardware has it (although it seems to be going out
> of fashion now on x86 boxes so maybe that's not such an issue at the moment)
Unfortunately yes, you only have this feature in some of Intels Extreme
versions
> DomU's VCPUs can be set to run on any thread context on the system.
Yes sure but that's not my point. As you describe a domU would use each
physical CPU it has access to but inside the domU each VCPU would look the
same, the guest cannot make any difference between logical CPUs and virtual
CPUs - it only has virtual CPUs then. But on the IBM platform the AIX guest
is still aware that there are two logical CPUs linked with one virtual CPU.
This is part of the hypervisor I think so the question is if Xen could also
virtualize logical CPUs. IBM has no SMT on the level of the hypervisor, here
they only have full physical CPUs. First in the logical partition you have
the ability to enable SMT in addition to the assigned VCPUs or to disable
it.
> I'm not sure to what extent guests are aware of the SMT so they can use it
> themselves; this would be particularly difficult for them to exploit given
> they could in theory be moved to other logical CPUs at any time.
The guest systems kernel does not really make a difference between logical
and virtual processors I think, it's only interest is to have two units to
send it's arithmetic problems to. But the whole guest operating system needs
to have the ability to enable or disable SMT. On AIX it is only one command
line but I'm sure it could be a point in the BIOS settings for Xen virtual
machines. Although I don't even know if I can edit the BIOS settings
directly when the vmachine starts up, never tried this :-) (with VMware you
can do this).
> Running dom0 in a dedicated thread context is useful though.
Absolutely. But I'm not sure if dom0_cpus=1 is everything I need because I
have no influence on Xen to only use one special core, in theory it can be
always another core in each time slice. Does Xen have the intelligence here
not to change the core? What about the guests, should I set cpus=1-7 in
their config files (with a total of 8 cores)? Would the hypervisor really
only use core 0 in that case?
Sorry for that annoying questions but I'd like to know it very exactly :-)
Cheers,
Julian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home