diff options
author | Nick Sayer <nsayer@FreeBSD.org> | 2001-03-07 18:04:10 +0000 |
---|---|---|
committer | Nick Sayer <nsayer@FreeBSD.org> | 2001-03-07 18:04:10 +0000 |
commit | 30bc1c26bb84a6c6e0cf917864dd5253e9dbfc4d (patch) | |
tree | 042349c13bd935d42b5fcd5eb25d280ac8cb76b9 /emulators/vmware3 | |
parent | c98e9942113f5af41dc1700af45508dbc5d6a556 (diff) | |
download | ports-30bc1c26bb84a6c6e0cf917864dd5253e9dbfc4d.tar.gz ports-30bc1c26bb84a6c6e0cf917864dd5253e9dbfc4d.zip |
Notes
Diffstat (limited to 'emulators/vmware3')
-rw-r--r-- | emulators/vmware3/files/Hints.FreeBSD | 55 |
1 files changed, 25 insertions, 30 deletions
diff --git a/emulators/vmware3/files/Hints.FreeBSD b/emulators/vmware3/files/Hints.FreeBSD index 9197a20849ba..15aa5a2f69dc 100644 --- a/emulators/vmware3/files/Hints.FreeBSD +++ b/emulators/vmware3/files/Hints.FreeBSD @@ -108,36 +108,31 @@ in /tmp and passes it to some external program; you'll see it actually creates a file in /compat/linux/tmp when the external program searches /tmp literally. -- There is a bug you may wish to work around. It is unclear (at least to -me) if this is a bug in VMware, the Linuxulator or the FreeBSD VM -system. - -Some background first: When you mmap a file, the syncer will attempt to -periodically synchronize the on-disk version of the file with the -changes being made in the mmap'd region. If you unlink an mmap'd file, -however, this no longer is necessary because if the machine were to -reboot fsck would throw the file away. The hint is given to the syncer -in the form of the MAP_NOSYNC flag to the mmap() syscall. - -The problem is that VMware somehow performs the operations differently -when resuming from a save-to-disk session than it does when booting. The -result is that the MAP_NOSYNC flag doesn't get set, which causes the -performance of a resumed session to be terrible compared to a new -session. - -I suspect that the problem is that when an open file is unlinked, the -unlink() call does not know to check to see if the file is mmap'ed and -if so to add the MAP_NOSYNC flag. This means that open(), unlink(), -mmap() sequences work, but open(), mmap(), unlink() sequences do not. -VMware probably does not unlink the save-to-disk file right away in case -the resume fails, which causes the difference in behavior compared to a -clean boot. - -The only workaround at present is to force all Linuxulator mmap() calls -to get MAP_NOSYNC. A patch against -current to do just this is available -at http://home.jp.FreeBSD.ORG/cgi-bin/showmail/FreeBSD-users-jp/55885 -(ignore the Japanese text if you can't read it. -stable users may need -to apply part of the patch to /sys/compat/linux/linux_mib.c). +- There is a bug you may wish to work around if you aren't running +5-current or a very recent 4-stable system. + +Some background first: With FreeBSD, when you mmap a file, the syncer +will attempt by default to periodically synchronize the on-disk version +of the file with the changes being made in the mmap'd region. You can +change this behavior using the MAP_NOSYNC flag to mmap(). With this +flag, the syncer will leave the dirty pages alone and only the +pagedaemon will flush them when it's absolutely necessary. However, +Linux always behaves as if the MAP_NOSYNC flag was given, but the +Linuxulator was not adding MAP_NOSYNC to the flags as part of the +compatibility layer. But that is ok, since unlinking the last reference +to an mmap()ed file causes FreeBSD to add MAP_NOSYNC in anyway (under +the theory that if the machine reboots in that situation the file's +inode would be freed since it would be an orphan). + +The problem is that VMware doesn't actually unlink the save-to-disk file +when resuming -- it merely uses it in place. The result is that the +MAP_NOSYNC flag doesn't get set, which causes the performance of a +resumed session to be terrible compared to a new session. Every time the +syncer runs (sysctl -a kern.filedelay), vmware hangs while the RAM file +dirty pages are flushed. + +This problem has been fixed in 4.2-STABLE as of 2 Mar 2001 +(sys/i386/linux/linux_machdep.c versions 1.13 and 1.6.2.3). - If you configure vmware to use bridging, you must still specify the "Host only" mode to the VMware configurator. It will still work just |