Date: Sun, 25 Feb 2001 21:59:08 -0800 From: Julian Elischer <julian@elischer.org> To: freebsd-emulation@freebsd.org Subject: Linuxulator and VMware fix Message-ID: <3A99F0AC.CEDE31CE@elischer.org>
next in thread | raw e-mail | index | archive | help
Matt Dillon wrote:
>
> :> Hacking vmware to set wired pages to PG_NOSYNC doesn't seem to help.
> :> However, I have my own local hack which seems to help a great deal:
> :> hacking the Linulator to treat all mmap'ed files as MAP_NOSYNC, in
> :> combination with my fixes to vm_fault so as to correctly tag a page in
> :> a MAP_NOSYNC map with PG_NOSYNC on a read fault.
[...]
> The vm_fault patch is correct. I was failing to set PG_NOSYNC for
> the write-wiring case on a read-fault (i.e. a read fault for which
> a later write is acceptable and will not cause another fault).
so is it applied?
can it be applied?
I don't have a copy of it so I don't know what it is.
Andrew, can you post your patches for the linuxulator too?
>
> :> of is adding some functionality to the vmmon kernel module to force
> :> the vmware app's mmap'ed regions to be MAP_NOSYNC. I don't know
> :> enough about how vmware works to achieve this & have not had the time
> :> to look into it further.
>
Vladimir says:
>
> Ok. From vmmon side memory wired in the next way:
> m = PHYS_TO_VM_PAGE(paddr);
> vm_page_wire(m);
>
> All those pages have a file as backed media (or in another words pages
> are coming from mmaped file). How file mmaped it's not handled vmmmon -
> vmmon just making lock/unlock memory and translation between virtual and
> physical addresses.
> :Matt and Vladimir, can the two of you figure out between you
> :how to do this? Vladimir knows the vmware side and Matt knows the VM options
> :available.
Matt says:
>
> My feeling is that the linux emulation patch should try to stick as
> close to linux as possible. So if Linux doesn't sync file-backed
> dirty pages, our linux emulation of their mmap() call shouldn't either.
>
The question is whether it syncs then "not at all", "when asked" or "whenever it
can"..
Do we have a mode of operation that matches what they do?
> For FreeBSD's native operation it's up in the air. Ultimately I believe
> that the way Linux is doing it (not syncing pages dirtied through mmap
> on a regular basis) is the way it will work in the future, for several
> reasons.
I assume this means the app must do an msync()?
Does exit() imply an msync()?
> First, file-backed writable mmap()'s (when used for
> persistent store reasons rather then IPC) are dangerous. Program
> memory corruption can leak through to the file.
> Second, except for
> the simplest of things (like a file copy), programmers generally need
> much finer control over write sequencing of sensitive data. Hence
> write() is used more often then a writeable mmap.
> Third, the
> distinction between file and anonymous-backed memory has become
> fuzzier and fuzzier over the years to the point where most people
> except mmap() to behave like normal VM behaves and less like write().
>
> Fourth, and most importantly, filesystems are getting closer and
> closer to becoming transactional. What we see now with journaling
> filesystems is but a poor imitation to what we are likely to see 10 years
> down the line. Transactional filesystems require an explicit
> understanding of what is dirty, in what order things should be
> committed, and must be able to handle parallel commits of non-conflicting
> data (just like a database with transactional capabilities is able
> to guarentee) - for a writable mmap()'d file this means using at least
> msync() rather then just assuming that modifying memory will result
> in proper ordering of writes to disk.
>
> So, for all those reasons, I believe that making MAP_NOSYNC the default
> for linux emulation is perfectly acceptable, and that we might even want
> to make it the default for FreeBSD (or at least try to apply our
> sequential detection heuristics to writable mmap()s to optimize
> sequential operations and treat the rest in a MAP_NOSYNC manner).
>
> -Matt
Ok so I suggest we get andrew's patches into the emulator at least.
Can someone who has Linux confirm that they in fact do act in this way?
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000-2001
---> X_.---._/
v
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?3A99F0AC.CEDE31CE>