Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Apr 2000 20:15:55 -0700
From:      "Sam Leffler" <sam@errno.com>
To:        "Guido van Rooij" <guido@gvr.org>, "Arjan de Vet" <Arjan.deVet@adv.iae.nl>
Cc:        <freebsd-emulation@FreeBSD.ORG>
Subject:   Re: Vmware 2.0 / NT4 / 100% system CPU time
Message-ID:  <01b501bf9de4$17595ce0$24a6d4d1@melange>
References:  <20000403150934.A11399@adv.iae.nl> <20000403230131.A16168@gvr.gvr.org>

next in thread | previous in thread | raw e-mail | index | archive | help
From: "Guido van Rooij" <guido@gvr.org>
To: "Arjan de Vet" <Arjan.deVet@adv.iae.nl>
Cc: <freebsd-emulation@FreeBSD.ORG>
Sent: Monday, April 03, 2000 2:01 PM
Subject: Re: Vmware 2.0 / NT4 / 100% system CPU time


> On Mon, Apr 03, 2000 at 03:09:34PM +0200, Arjan de Vet wrote:
> >
> > This works OK except for the fact that when doing nothing in the virtual
> > PC (according to NT perf.mon.) it uses 98-100% system CPU time and using
> > truss I only see this being repeated all the time at an enormous speed:
>
> This did not happen a couple of months ago.
>
> >
> >     syscall linux_newselect(0x15,0xbfbff474,0x0,0x0,0xbfbff468)
> >     returns 0 (0x0)
> >     syscall linux_ioctl(0xa,0xcb,0xbfbff540)
> >     returns 311 (0x137)
> >     syscall gettimeofday(0xbfbff4e8,0x0)
> >     returns 0 (0x0)
> >     syscall linux_newselect(0x15,0xbfbff474,0x0,0x0,0xbfbff468)
> >     returns 0 (0x0)
> >     syscall linux_ioctl(0xa,0xcb,0xbfbff540)
> >     returns 311 (0x137)
> >     syscall gettimeofday(0xbfbff4e8,0x0)
> >     returns 0 (0x0)
> >
>
> This ioctl is defined in vmmon:
>
/usr/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/include/iocontro
ls.h
>
> and seems to be IOCTLCMD_RUN. This seems to be the main interface from
> VMware towards the vmmon module.
> It strikes me as odd though that it has to be called 20+ times a second.
> I am sure that it didn't use to be that way....
>
> If Sam is listening: is this caused by a difference between vmware 1.2 and
2.0?
>

No. The RUN ioctl is the mechanism used to (re-)enter the virtual machine
from user mode.  There are lots of reasons that execution may temporarily
return to the user level app (e.g. to service i/o).  You don't indicate if
the system is UP or MP; if the latter try a UP system.  I'm also assuming
you're running from a virtual disk and not a raw partition.  Otherwise look
for FreeBSD changes related to handling timers; that's always been a tricky
part of the integration process.  Of course all this is just wild
guessing...

    Sam




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01b501bf9de4$17595ce0$24a6d4d1>