[rhelv6-beta-list] why rhel-6 still not a good choice for a programmer

[Bryan J. Smith]

Luke S Crawford <lsc at prgmr.com> wrote:
> The problem is that you want to make your virtualization
> control host (what we called the Dom0 in xen) as small as
> possible.   A 64 bit host, all other things being equal, will
> eat more ram.

Understand this argument doesn't hold much water in my experience,
and that dates back to 2004 shoartly after x86-64 first appeared.
Efficiency in the userspace has far more to do with things than select
sizing on the platform.

Furthermore, both x86-64 and x86 normalize from 48-bit pointers 
-- the former is flat (Long Mode), the latter is segmented.
So the alleged "inefficiency" of Long Mode is grossly overstated.
Especially when it actually comes to packing the bits.

The bigger issue with x86-64 has to do with loading the foreign
32-bit targets (32-bit libraries) on 48-bit kernel memory models, in
addition to the native 48-bit targets (64-bit libraries).  So if you
have a "lean'n clean" dom0, with native 48-bit targets only, this is
not much of an issue.

The problem is always polluting it with 32-bit targets, which you
should _not_ be doing, or at least not mixing with 48-bit Long Mode
targets.

> The commercial distribution of xen from citrix runs a 64-bit
> hypervisor, but it runs a 32 bit dom0, to save on ram.  (It supports
> both 32 and 64 bit guests.)

Yes, and Microsoft ships a lot of 32-bit userspace too, even for the
48-bit Long Mode kernel.  But at some point the two sets of targets
can actually be _less_ efficient.  Microsoft actually does it for
backward compatibility more than memory efficiency.

I've seen this as the case in other environments too, like Citrix.
Sometimes it's easier to just have a single, legacy, 32-bit target,
even when the kernel is 48-bit Long Mode.

> Now, I don't think this (making the driver domain 32 bit
> and the hypervisor 64 bit) is possible under kvm because the
> driver domain /is/ the hypervisor...

Untrue.

The host OS or, if you want to call it, "helper" or "minimal" OS,
is the host OS.  The choice of 32-bit targets have more to do with
legacy compatibility than sizing.

KVM, Xen and even VMware have a "helper" OS, regardless of product.
Yes, even the alleged "standalone" HyperVisors have a minimal "helper"
OS in that little USB key.  ;)

> I'm just saying, there /are/ cases where it is benificial to run
> 32-bit.  

Legacy compatibility is a biggy.

48-bit Long Mode targets cannot use 32-bit libraries and 32-bit
targets cannot use 48-bit Long Mode libraries.  So you have redundancy.

Some vendors just choose to ignore the 48-bit objects altogether,
except when absolutely required for services.

-- Bryan

P.S.  I blogged this 5 years ago after tiring of explaining it for
over a good year:  
  http://thebs413.blogspot.com/2005/10/what-is-x86-64-long-mode-memory-model.html  


-- 
Bryan J  Smith             Professional, Technical Annoyance 
Linked Profile:           http://www.linkedin.com/in/bjsmith 
------------------------------------------------------------ 
"Now if you own an automatic ... sell it!
 You are totally missing out on the coolest part of driving"
                                         -- Johnny O'Connell