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
Suse.
> 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: