[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Alternative to 64/32 hybrid - 32 bit UML

On Wednesday 03 September 2003 08:30 am, Dan Shearer wrote:
> On Wed, Sep 03, 2003 at 10:41:25PM +0930, Dan Shearer wrote:
> > UML should be hardly noticeable as an emulation layer if packaged
> > correctly.

No.  That's a *very* bad approach, for several reasons:

UML is NOT a program emulation layer, it is a SEPARATE OS INSTANCE.  That 
means you'll need essentially the guts of a Linux distribution for each UML 
you start up.  That's a significant amount of extra management for someone 
that just wants to run one or two 32-bit apps.

UML is NOT a lightweight beast.  Pretty much all IO though UML is quite slow 
- a horrible tradeoff for people with performance needs for their 32-bit 
apps (and there are a lot of those people - think of the vast numbers of 
cluster users out there buying Opterons now).

UML is NOT flexible - you have to give it a chunk of RAM when it starts.  
What if your 32-bit app suddenly needs more memory than you initially gave 
it?  Oops, gotta reboot the emulator.  If you guess too high and give the 
emulator too much memory you end up starving the host environment.  That's 
just a pain in the ass waiting to happen.

> Just to qualify a little: I am thinking of servers (where Opterons are
> most likely to be used at the time Sarge is released) and of
> longer-running processes so that the startup time, which can already be
> trimmed right down, is negligible. Nobody normally cares if Apache takes
> another 0.25 seconds to start up an instance. If someone is after
> performance they'll use a 64-bit binary anyway. If someone wants a
> 32-bit /bin/ls then they're a corner case.

I want performance on 32-bit binaries.  Why?  Because I use 3rd party 
software that's not built for Opterons.  Sometimes my 32-bit stuff needs a 
small amount of memory, sometimes a lot.  I'm not going to want to 
sacrifice flexibility on this; I'd rather just bite the bullet and go with 

> Incidentally, as to whether or not a 64-bit-only solution would be
> useful, I contribute my own experience. I do a lot of my desktop work on
> an old Alpha running Sid. Not because I particularly like Alphas, but
> because it gives me a very good feeling for what works 64-bit and what
> doesn't. And the answer is that despite gloomy comments on this list,
> there is very little on the desktop that doesn't work and almost nothing
> on the server side.

I'm pretty sure no one here is arguing that Debian packages won't work in 
64-bit.  I use an UltraSPARC; life is fine (as well as on the Itanium2 
nodes at work).  Whether or not 64-bit packages will work isn't the issue, 
it's how to support 32-bit stuff alongside the 64-bit.

DEC didn't use a full virtualized OS like UML to support their 32-bit (IA32) 
emulation layer.  They used a wonderful little binary emulator, but it 
didn't emulate an OS.  It merely executed IA32 instructions and provided 
syscall translation to the underlying Unix core.  Such functionality is 
already provided in an Opteron processor and kernel (instruction execution 
is native to the proc, syscall emulation and the like in the kernel).  
That's a good approach; it lets 32-bit apps run alongside 64-bit apps with 
no hassles.

If you throw UML into the mix you add a second kernel, trying to do its own 
memory management on top of the underlying kernel.  You can't directly 
interoperate with the 32-bit process, you have to go through (essentially) 
another machine first.  That's insane, especially when faster, more 
convienient support already exists.

> I really think that this list is greatly overrating the usefulness of
> 32-bit compatibility on the server side. Workstations, quite possibly.
> But servers?  I doesn't make much sense to me.

I run a good-sized Linux cluster - essentially a few hundred servers.  We're 
beginning to branch out from i686 procs to Itanium and Opterons.  Opterons 
are quite nice because of the 32-bit compatibility on the servers.  Some of 
our clients have no problems rebuilding their code; others rely on 3rd 
party 32-bit only binaries.  With a proper OS on the Opterons we can 
support both.

> When a server administrator gets a chance to wring a few percentage
> points of extra performance out of his hardware raid or network card, he
> usually does by installing a better driver if one is available. Even if
> the performance isn't really required or noticeable! So people are
> suggesting that owners of expensive brand-new Operterons are going to
> want to do dist-upgrade from old system partitions rather than install
> from scratch? I don't think so. 64-bit Opteron works faster and has the
> memory model. Too good to miss.

True - few sysadmins are going to bother dist-upgrading their Opterons, 
rather than reinstalling.  However, if you allow for full compatibility 
between 32-bit and 64-bit userlands you should be able to get this minor 
feature essentially for free.

Personally, I'd prefer that Debian not have an Opteron port shipping with 
Sarge.  I'd rather things were done right the first time, allowing full 
64-bit and 32-bit interoperability.  Hell, I'd even be willing to sink some 
time into working on this, if necessary.

Mike Shuey

Reply to: