[Fwd: [Bug 817] New: DMX includes <linux/input.h>onnon-Linuxplatforms]

Roland Mainz roland.mainz at nrubsig.org
Tue Jul 6 23:28:57 PDT 2004


Daniel Stone wrote:
> > > > For x86 platforms I may have a better solution: We could simply fetch a
> > > > x86 machine with >=1GHz, >=1GB memory, install VMware on it and then can
> > > > run MANY MANY VMware VMs on it, - one for Solaris2.8/x86, one for
> > > > Solaris 2.9/x86, one for SuSE Linux, one for Debian Linux, one for
> > > > NetBSD, one for FreeBSD and there is still memory left for more VMs.
> > > > And we would be able to use the same machine for building binaries for
> > > > these platforms, too... :)
> > >
> > > I have an AthlonXP 2400+ (raw clock 2GHz), and VMware is really quite
> > > slow on it - my Windows sessions crawl.
> >
> > Please check your configuration. We are running VMware "servers" here
> > (to be exact: VMware Workstation on headless AMD Athlon machines) with
> > up to 8 VMs (we could do more per server - but the network is usually
> > the bottleneck since we don't have everywhere 1Gbit and if four users
> > share one 100baseT pipe it may quickly get saturated if everyone runs
> > realplayer) in parallel which provide windows services (e.g. WinNT4.0,
> > Win2000, WinXP) and various other OSes (Solaris x86, Linux/x86 etc.) to
> > our Sun machines. Works perfectly.
> >
> > BTW: Win95/Win98/WinME and MS-DOS applications are slow as snails
> > because the underlying "OS" doesn't call "HLT" when being idle. And
> > don't forget to install the Vmware Tools and VMWare VGA driver on the
> > Windows OSes.
> 
> I don't remember the configuration, but it was pretty slow, no matter
> what I did. It certainly wasn't *faster* than under the host OS - I'll
> tell you that now.

Just to clarify: The CPU won't become faster (AFAIK the Transmeta CPUs
are the only CPUs which may become faster with software updates :), only
the disk I/O when being measured within the guest OS - which is a
side-effect of caching in the VM layer.

> > > I wouldn't want to be trying to
> > > build the monolithic tree under that, really.
> >
> > I am doing this already with SuSE 8.2 as host OS and SuSE9.1/Solaris9 as
> > guest OSes and don't have performace problems on my laptop. Mozilla
> > debug builds within the VM may even be faster than running natively on
> > the host OS (because they are I/O-bound, not CPU-bound - the VMware VM
> > caches disk I/O which boots performace in such scenarios a lot (WARNING:
> > If the host crashes or gets turned OFF a logging filesystem within the
> > guest OS is of little use... in cases where it is important to gurantee
> > filesystem consistency it is better to run the critical stuff on a NFS
> > filesystem)) ... :)
> 
> I've actually found that NFS is probably the best way to throw data away
> ... but there you go.

Well, I guess this is a problem of the (old ?!) Linux NFS
implementations. Linux NFS client and Solaris NFS server was working
quite well (excluding the issue with locking and the slow performance
due the Linux implementation, but I hope both issues are now fixed in
the Linux 2.6.x kernel series).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)



More information about the release-wranglers mailing list