Re: What's changed recently with vmware/linuxemu/file I/O
Andrew Gallatin writes: Dag-Erling Smorgrav writes: Julian Elischer [EMAIL PROTECTED] writes: I believe that vmware mmaps a region of memory and then somehow syncs it to disk. (It is certainly doing something like it here). Theory: VMWare mmaps a region of memory corresponding to the virtual machine's "physical" RAM, then touches every page during startup. Unless some form of clustering is done, this causes 16384 write operations for a 64 MB virtual machine... Pretty much. But the issue is that this should never hit the disk unless we're under memory pressure because it is mapped MAP_NOSYNC (actually the file is unlinked prior to the mmap() and a heuristic in vm_mmap() detects this and sets MAP_NOSYNC). I take it back. At least with the latest version of vmware, it is apparently not mapped MAP_NOSYNC. I think they've moved from mmap'ing a file in $TMPDIR to just using the CONFIG.std save/resume file. Perhaps this is only if you have resumed from a suspended state... I haven't checked that out yet. At any rate, hacking linux_mmap to ad MAP_NOSYNC to mmaped files, in combination with yesterdays patch, appears to improve perf. considerably. Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Andrew Gallatin wrote: Andrew Gallatin writes: Dag-Erling Smorgrav writes: Julian Elischer [EMAIL PROTECTED] writes: I believe that vmware mmaps a region of memory and then somehow syncs it to disk. (It is certainly doing something like it here). Theory: VMWare mmaps a region of memory corresponding to the virtual machine's "physical" RAM, then touches every page during startup. Unless some form of clustering is done, this causes 16384 write operations for a 64 MB virtual machine... Pretty much. But the issue is that this should never hit the disk unless we're under memory pressure because it is mapped MAP_NOSYNC (actually the file is unlinked prior to the mmap() and a heuristic in vm_mmap() detects this and sets MAP_NOSYNC). I take it back. At least with the latest version of vmware, it is apparently not mapped MAP_NOSYNC. I think they've moved from mmap'ing a file in $TMPDIR to just using the CONFIG.std save/resume file. Perhaps this is only if you have resumed from a suspended state... I haven't checked that out yet. At any rate, hacking linux_mmap to ad MAP_NOSYNC to mmaped files, in combination with yesterdays patch, appears to improve perf. considerably. I don't like the sound of that hack.. are they doing something in Linux to tell Linux to not sync it? I nkow it's gross but could we only do that hack if it'a vmware? (probably should be on -emulation) Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Wed, Feb 07, 2001 at 10:07:06PM -0500, Robert Watson wrote:
On 7 Feb 2001, Dag-Erling Smorgrav wrote:
Brian Somers [EMAIL PROTECTED] writes:
Indeed. I've been doing a ``make build'' on an OpenBSD-current vm
for three days (probably about 36 hours excluding suspends) on a
366MHz laptop with a ATA33 disk.
Would it be possible for someone experiencing this slowdown to try to
narrow down the day (or even the week) on which it occurred?
I've experienced a substantial slowdown in VMware since bumping forwards
from -STABLE on my workstation. As I recently commented on -emulation,
I've also been experiencing 30-40 second hangs of the system during VMware
startup and occasional serious slowdown while running, which may be
related to the fairly intensive VM activity for page wiring and the like,
or possible poor interaction with the ATA driver. I also get messages on
the order of the following:
The slowdown during start up appears to be in biowr; this is probably
because of IDE write caching being switched off. More seriously
the vmware hangs during various phases of it's boot process.
i.e:
714 root -14 0 123M 79192K inode0:45 25.29% 25.29% vmware
When this happens the whole machine freezes also. Processes run, but
new processes don't get forked. The whole machine appears to be I/O
bound. (What's the 'inode' state?)
The problem is definitely solved by enabling ATA_ENABLE_WC in the kernel
config. What's unclear to me is why the hang in 'inode' with it
switched off. I understand that biowr's would take longer, which is
vmware does as it brings up the virtual machine, but why the hanging
and freezing in 'inode'?
Joe
RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.91
retrieving revision 1.92
diff -u -r1.91 -r1.92
--- ata-disk.c 2001/01/19 13:53:54 1.91
+++ ata-disk.c 2001/01/29 18:00:35 1.92
@@ -25,7 +25,7 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
- * $FreeBSD: src/sys/dev/ata/ata-disk.c,v 1.91 2001/01/19 13:53:54 peter Exp $
+ * $FreeBSD: src/sys/dev/ata/ata-disk.c,v 1.92 2001/01/29 18:00:35 sos Exp $
*/
#include "opt_global.h"
@@ -133,10 +133,15 @@
0, 0, 0, 0, ATA_C_F_ENAB_RCACHE, ATA_WAIT_INTR))
printf("ad%d: enabling readahead cache failed\n", adp-lun);
+#if defined(ATA_ENABLE_WC) || defined(ATA_ENABLE_TAGS)
if (ata_command(adp-controller, adp-unit, ATA_C_SETFEATURES,
0, 0, 0, 0, ATA_C_F_ENAB_WCACHE, ATA_WAIT_INTR))
printf("ad%d: enabling write cache failed\n", adp-lun);
-
+#else
+if (ata_command(adp-controller, adp-unit, ATA_C_SETFEATURES,
+ 0, 0, 0, 0, ATA_C_F_DIS_WCACHE, ATA_WAIT_INTR))
+ printf("ad%d: disabling write cache failed\n", adp-lun);
+#endif
/* use DMA if drive controller supports it */
ata_dmainit(adp-controller, adp-unit,
ata_pmode(AD_PARAM), ata_wmode(AD_PARAM), ata_umode(AD_PARAM));
PGP signature
Re: What's changed recently with vmware/linuxemu/file I/O
Josef Karthauser wrote:
The slowdown during start up appears to be in biowr; this is probably
because of IDE write caching being switched off. More seriously
the vmware hangs during various phases of it's boot process.
Write caching is incompaible with soft updates.
The drive must NEVER report that something is on disk when it really is not!
i.e:
714 root -14 0 123M 79192K inode0:45 25.29% 25.29% vmware
When this happens the whole machine freezes also. Processes run, but
new processes don't get forked. The whole machine appears to be I/O
bound. (What's the 'inode' state?)
this sounds like a differnt starvation problem.
when it's happenning, what does 'iostat 1' show?
(how many transactions per second?)
I believe that vmware mmaps a region of memory and then somehow syncs
it to disk. (It is certainly doing something like it here).
The problem is definitely solved by enabling ATA_ENABLE_WC in the kernel
config. What's unclear to me is why the hang in 'inode' with it
switched off. I understand that biowr's would take longer, which is
vmware does as it brings up the virtual machine, but why the hanging
and freezing in 'inode'?
maybe syncing mmapped regions locks out other types of activity?
Matt?
+#else
+if (ata_command(adp-controller, adp-unit, ATA_C_SETFEATURES,
+ 0, 0, 0, 0, ATA_C_F_DIS_WCACHE, ATA_WAIT_INTR))
+ printf("ad%d: disabling write cache failed\n", adp-lun);
+#endif
we used to do this on the interjet because we ran soft updates.
--
__--_|\ Julian Elischer
/ \ [EMAIL PROTECTED]
( OZ) World tour 2000-2001
--- X_.---._/
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Thu, Feb 08, 2001 at 04:08:12AM -0800, Julian Elischer wrote: Josef Karthauser wrote: 714 root -14 0 123M 79192K inode0:45 25.29% 25.29% vmware When this happens the whole machine freezes also. Processes run, but new processes don't get forked. The whole machine appears to be I/O bound. (What's the 'inode' state?) this sounds like a differnt starvation problem. when it's happenning, what does 'iostat 1' show? (how many transactions per second?) It looks like below. Joe tty ad0 fd0 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 179 8.00 67 0.53 0.00 0 0.00 0 0 0 2 98 0 59 8.00 68 0.53 0.00 0 0.00 0 0 0 2 98 0 60 8.00 68 0.53 0.00 0 0.00 0 0 0 2 98 0 60 8.00 67 0.53 0.00 0 0.00 2 0 0 2 97 0 59 8.00 66 0.52 0.00 0 0.00 1 0 2 2 95 0 60 8.00 68 0.53 0.00 0 0.00 1 0 1 2 97 0 60 8.00 68 0.53 0.00 0 0.00 0 0 1 2 98 0 60 8.00 67 0.53 0.00 0 0.00 0 0 1 1 98 0 59 8.00 66 0.52 0.00 0 0.00 0 0 0 2 98 79 60 8.00 67 0.53 0.00 0 0.00 0 0 1 2 98 183 60 8.00 68 0.53 0.00 0 0.00 0 0 3 2 95 143 60 8.00 67 0.53 0.00 0 0.00 0 0 3 3 94 197 59 8.00 67 0.53 0.00 0 0.00 1 0 1 2 97 48 60 8.00 68 0.53 0.00 0 0.00 0 0 0 2 98 8 60 8.00 67 0.53 0.00 0 0.00 0 0 2 2 96 228 59 8.00 66 0.52 0.00 0 0.00 1 0 2 2 96 40 60 8.00 67 0.53 0.00 0 0.00 0 0 2 2 96 0 60 8.00 68 0.53 0.00 0 0.00 1 0 1 2 97 0 60 8.00 67 0.53 0.00 0 0.00 1 0 1 3 95 0 59 8.00 67 0.53 0.00 0 0.00 1 0 1 2 97 tty ad0 fd0 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 179 8.00 68 0.53 0.00 0 0.00 0 0 2 2 97 0 60 8.00 67 0.53 0.00 0 0.00 1 0 1 2 96 0 59 8.00 67 0.53 0.00 0 0.00 0 0 0 3 97 0 60 8.00 67 0.53 0.00 0 0.00 0 0 0 2 98 0 60 8.00 68 0.53 0.00 0 0.00 1 0 0 2 98 0 60 8.00 67 0.53 0.00 0 0.00 0 0 0 2 98 0 59 8.00 68 0.53 0.00 0 0.00 1 0 0 2 98 0 60 8.00 67 0.53 0.00 0 0.00 0 0 0 2 98 0 60 8.00 68 0.53 0.00 0 0.00 0 0 1 2 98 0 59 8.00 67 0.53 0.00 0 0.00 0 0 2 2 95 0 60 8.00 68 0.53 0.00 0 0.00 0 0 1 3 96 0 60 8.00 68 0.53 0.00 0 0.00 2 0 1 2 95 0 60 8.00 67 0.53 0.00 0 0.00 0 0 0 2 98 0 59 8.00 68 0.53 0.00 0 0.00 0 0 0 2 98 0 60 8.00 67 0.53 0.00 0 0.00 0 0 0 2 98 0 60 8.00 68 0.53 0.00 0 0.00 0 0 0 2 98 0 59 8.00 66 0.52 0.00 0 0.00 0 0 0 2 98 0 60 8.00 66 0.52 0.00 0 0.00 0 0 0 2 98 0 60 8.00 67 0.53 0.00 0 0.00 0 0 0 2 98 0 60 8.00 68 0.53 0.00 0 0.00 0 0 0 2 98 PGP signature
Re: What's changed recently with vmware/linuxemu/file I/O
Josef Karthauser wrote: On Thu, Feb 08, 2001 at 04:08:12AM -0800, Julian Elischer wrote: Josef Karthauser wrote: 714 root -14 0 123M 79192K inode0:45 25.29% 25.29% vmware When this happens the whole machine freezes also. Processes run, but new processes don't get forked. The whole machine appears to be I/O bound. (What's the 'inode' state?) this sounds like a differnt starvation problem. when it's happenning, what does 'iostat 1' show? (how many transactions per second?) It looks like below. Looks like some way of clustering this might achieve a lot. what does systat -vmstat or vmstat 1 show? Better still, I guess we could do a linux-truss and see what it's doing... Joe tty ad0 fd0 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 179 8.00 67 0.53 0.00 0 0.00 0 0 0 2 98 0 59 8.00 68 0.53 0.00 0 0.00 0 0 0 2 98 0 60 8.00 68 0.53 0.00 0 0.00 0 0 0 2 98 0 60 8.00 67 0.53 0.00 0 0.00 2 0 0 2 97 -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Julian Elischer [EMAIL PROTECTED] writes: I believe that vmware mmaps a region of memory and then somehow syncs it to disk. (It is certainly doing something like it here). Theory: VMWare mmaps a region of memory corresponding to the virtual machine's "physical" RAM, then touches every page during startup. Unless some form of clustering is done, this causes 16384 write operations for a 64 MB virtual machine... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Thu, Feb 08, 2001 at 04:58:17AM -0800, Julian Elischer wrote: Looks like some way of clustering this might achieve a lot. what does systat -vmstat or vmstat 1 show? Better still, I guess we could do a linux-truss and see what it's doing... I believe that it's strace under linux. If someone can provide me with a binary of this tool I'll happily run it here and see what vmware's doing. Joe PGP signature
Re: What's changed recently with vmware/linuxemu/file I/O
On Thu, Feb 08, 2001 at 02:47:59PM +, Josef Karthauser wrote: what does systat -vmstat or vmstat 1 show? Better still, I guess we could do a linux-truss and see what it's doing... I believe that it's strace under linux. If someone can provide me with a binary of this tool I'll happily run it here and see what vmware's doing. You could use FreeBSD ktrace and then the linux_kdump port. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Thu, Feb 08, 2001 at 04:58:17AM -0800, Julian Elischer wrote: =20 Looks like some way of clustering this might achieve a lot. =20 what does systat -vmstat or vmstat 1 show? Better still, I guess we could do a linux-truss and see what it's doing... I believe that it's strace under linux. If someone can provide me with a binary of this tool I'll happily run it here and see what vmware's doing. Joe The problem seems to have gone away after this (kindly pointed out to me by Maxim after my other post about xsane dropping cores): : Subject: cvs commit: src/lib/libc/stdio findfp.c : Date: Wed, 7 Feb 2001 09:34:50 -0800 (PST) : From: Maxim Sobolev [EMAIL PROTECTED] : To: [EMAIL PROTECTED], [EMAIL PROTECTED] : : sobomax 2001/02/07 09:34:49 PST : : Modified files: : lib/libc/stdio findfp.c : Log: : Fix a f^Hdamn typo, which prevented to fopen() more that 17 files at once. : : Tested by: knu, sobomax and other #bsdcode'rs : : Revision ChangesPath : 1.9 +2 -2 src/lib/libc/stdio/findfp.c -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Dag-Erling Smorgrav writes:
Julian Elischer [EMAIL PROTECTED] writes:
I believe that vmware mmaps a region of memory and then somehow syncs
it to disk. (It is certainly doing something like it here).
Theory: VMWare mmaps a region of memory corresponding to the virtual
machine's "physical" RAM, then touches every page during startup.
Unless some form of clustering is done, this causes 16384 write
operations for a 64 MB virtual machine...
Pretty much. But the issue is that this should never hit the disk
unless we're under memory pressure because it is mapped MAP_NOSYNC
(actually the file is unlinked prior to the mmap() and a heuristic in
vm_mmap() detects this and sets MAP_NOSYNC).
The real problem is that our MAP_NOSYNC doesn't fully work in at least
one major case. As I understand it, the technique we use is to set
the MAP_ENTRY_NOSYNC in the map entry at mmap time. On a write fault,
PG_NOSYNC is set in the page's flags. A lazy msync will skip
PG_NOSYNC pages.
The problem comes when a page is read from prior to being written
to. The page gets mapped in read/write and we don't take a write
fault, so the PG_NOSYNC flag never gets set. (This accounts for the
flurry of disk i/o shortly after vmware starts). When the pages get
sunk to disk, the vnode is locked and the application will freeze in a
"vmpfw"
The following patch sets PG_NOSYNC on faults other than write faults.
This seems to work for my test program, and for vmware (I've only very
briefly tested it). Assuming that it is correct, the code around it
should be reorganized somewhat. This is against -stable, as I don't
have any -current i386s..
Index: vm_fault.c
===
RCS file: /home/ncvs/src/sys/vm/vm_fault.c,v
retrieving revision 1.108.2.2
diff -u -r1.108.2.2 vm_fault.c
--- vm_fault.c 2000/08/04 22:31:11 1.108.2.2
+++ vm_fault.c 2001/02/08 23:04:02
@@ -804,6 +804,10 @@
}
vm_page_dirty(fs.m);
vm_pager_page_unswapped(fs.m);
+ } else {
+ if ((fs.entry-eflags MAP_ENTRY_NOSYNC)
+ (fs.m-dirty == 0))
+ vm_page_flag_set(fs.m, PG_NOSYNC);
}
}
Cheers,
Drew
--
Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science Phone: (919) 660-6590
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
David Malone wrote: On Thu, Feb 08, 2001 at 02:47:59PM +, Josef Karthauser wrote: what does systat -vmstat or vmstat 1 show? Better still, I guess we could do a linux-truss and see what it's doing... I believe that it's strace under linux. If someone can provide me with a binary of this tool I'll happily run it here and see what vmware's doing. You could use FreeBSD ktrace and then the linux_kdump port. David. I believe truss can do linux binaries which is why I mantionned it. (but I have never done it) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Wed, 7 Feb 2001, Josef Karthauser wrote: On Wed, Feb 07, 2001 at 08:56:14PM +, Josef Karthauser wrote: On Wed, Feb 07, 2001 at 08:26:15PM +0100, Dag-Erling Smorgrav wrote: Brian Somers [EMAIL PROTECTED] writes: Indeed. I've been doing a ``make build'' on an OpenBSD-current vm for three days (probably about 36 hours excluding suspends) on a 366MHz laptop with a ATA33 disk. Would it be possible for someone experiencing this slowdown to try to narrow down the day (or even the week) on which it occurred? As I think about it it was definitity working before the symbol changes in libc/libc_r changed. Was that last week? No probably the week before. It was working fine last week, but I'm not sure which day's I updated the kernel. I'll try some builds. Ok. The problem definitely began between -D2001-01-29 and -D2001-01-30. I'll try and binary chop to workout what caused it. If you have ata disks, try "options ATA_ENABLE_WC". Nothing else has changed significantly in this period. I don't know how this would effect vmware boot speeds. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Wed, Feb 07, 2001 at 08:26:15PM +0100, Dag-Erling Smorgrav wrote: Brian Somers [EMAIL PROTECTED] writes: Indeed. I've been doing a ``make build'' on an OpenBSD-current vm for three days (probably about 36 hours excluding suspends) on a 366MHz laptop with a ATA33 disk. Would it be possible for someone experiencing this slowdown to try to narrow down the day (or even the week) on which it occurred? As I think about it it was definitity working before the symbol changes in libc/libc_r changed. Was that last week? No probably the week before. It was working fine last week, but I'm not sure which day's I updated the kernel. I'll try some builds. Joe PGP signature
Re: What's changed recently with vmware/linuxemu/file I/O
Brian Somers [EMAIL PROTECTED] writes: Indeed. I've been doing a ``make build'' on an OpenBSD-current vm for three days (probably about 36 hours excluding suspends) on a 366MHz laptop with a ATA33 disk. Would it be possible for someone experiencing this slowdown to try to narrow down the day (or even the week) on which it occurred? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On 7 Feb 2001, Dag-Erling Smorgrav wrote: Brian Somers [EMAIL PROTECTED] writes: Indeed. I've been doing a ``make build'' on an OpenBSD-current vm for three days (probably about 36 hours excluding suspends) on a 366MHz laptop with a ATA33 disk. Would it be possible for someone experiencing this slowdown to try to narrow down the day (or even the week) on which it occurred? I've experienced a substantial slowdown in VMware since bumping forwards from -STABLE on my workstation. As I recently commented on -emulation, I've also been experiencing 30-40 second hangs of the system during VMware startup and occasional serious slowdown while running, which may be related to the fairly intensive VM activity for page wiring and the like, or possible poor interaction with the ATA driver. I also get messages on the order of the following: swap_pager: indefinite wait buffer: device: ad0s1b, blkno: 2696, size: 4096 And have heard that others have started getting them also, although don't have confirmation of that. It may be that things need retuning a bit in -CURRENT, or that we need to wait for SMPng to do some pushdown of locks. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Wed, Feb 07, 2001 at 08:56:14PM +, Josef Karthauser wrote: On Wed, Feb 07, 2001 at 08:26:15PM +0100, Dag-Erling Smorgrav wrote: Brian Somers [EMAIL PROTECTED] writes: Indeed. I've been doing a ``make build'' on an OpenBSD-current vm for three days (probably about 36 hours excluding suspends) on a 366MHz laptop with a ATA33 disk. Would it be possible for someone experiencing this slowdown to try to narrow down the day (or even the week) on which it occurred? As I think about it it was definitity working before the symbol changes in libc/libc_r changed. Was that last week? No probably the week before. It was working fine last week, but I'm not sure which day's I updated the kernel. I'll try some builds. Ok. The problem definitely began between -D2001-01-29 and -D2001-01-30. I'll try and binary chop to workout what caused it. Joe PGP signature
Re: What's changed recently with vmware/linuxemu/file I/O
Josef Karthauser wrote: Hi, I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Joe Part 1.2Type: application/pgp-signature I noticed this too. It's about 3 x slower for me. Even the startup sequence when we haven't even loaded the bootblocks is MUCH slower.. I'm using vmware 1.0.x and running FreeBSD on it for kernel debugging. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Tue, 6 Feb 2001, Josef Karthauser wrote: I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. Use of cmpxchg and possibly other SMP pessimizations. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Read your freebsd-emulation mail :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
On Wed, Feb 07, 2001 at 02:40:27AM +1100, Bruce Evans wrote: Could someone please hit me with a clue-bat :) Read your freebsd-emulation mail :-). /me wanders off to subscribe to freebsd-emulation. Thanks Bruce. Joe PGP signature
Re: What's changed recently with vmware/linuxemu/file I/O
Bruce Evans wrote: On Tue, 6 Feb 2001, Josef Karthauser wrote: I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. Use of cmpxchg and possibly other SMP pessimizations. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Read your freebsd-emulation mail :-). You are wrong Bruce, the cmpxchg discussion was regarding why running FreeBSD as a GUEST OS was slow, because the virtual machine was very slow at emulating them. That does not explain why Windows2000 and the Boot loader both slowed down by a factor or 3-6 over teh last 2 weeks. It's even slower to start up, before it has even started any emulation.. This feels like the system is massively slowing down page activations or some other sort of exceptions that are standard for vmware. The same vmware with the same guest OS (not been updated) is now much slower. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's changed recently with vmware/linuxemu/file I/O
Bruce Evans wrote: On Tue, 6 Feb 2001, Josef Karthauser wrote: I'm wondering what's changed recently to cause vmware2 running on the linuxemu to lose a lot of performance with disk I/O. Use of cmpxchg and possibly other SMP pessimizations. A couple of weeks ago I could boot win2000 under vmware2 in a matter of minutes; on today's kernel it takes 5 or 10 minutes to boot, and disk I/O is through the roof. Could someone please hit me with a clue-bat :) Read your freebsd-emulation mail :-). You are wrong Bruce, the cmpxchg discussion was regarding why running FreeBSD as a GUEST OS was slow, because the virtual machine was very slow at emulating them. That does not explain why Windows2000 and the Boot loader both slowed down by a factor or 3-6 over teh last 2 weeks. It's even slower to start up, before it has even started any emulation.. This feels like the system is massively slowing down page activations or some other sort of exceptions that are standard for vmware. The same vmware with the same guest OS (not been updated) is now much slower. Indeed. I've been doing a ``make build'' on an OpenBSD-current vm for three days (probably about 36 hours excluding suspends) on a 366MHz laptop with a ATA33 disk. This is on a Feb 4 kernel. NetBSD next -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 --- X_.---._/ v -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
