From owner-freebsd-emulation Sun Feb 25 21:59:53 2001 Delivered-To: freebsd-emulation@freebsd.org Received: from syncopation-03.iinet.net.au (syncopation-03.iinet.net.au [203.59.24.49]) by hub.freebsd.org (Postfix) with SMTP id 5E7CA37B491 for ; Sun, 25 Feb 2001 21:59:48 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 15859 invoked by uid 666); 26 Feb 2001 06:11:51 -0000 Received: from i091-108.nv.iinet.net.au (HELO elischer.org) (203.59.91.108) by mail.m.iinet.net.au with SMTP; 26 Feb 2001 06:11:51 -0000 Message-ID: <3A99F0AC.CEDE31CE@elischer.org> Date: Sun, 25 Feb 2001 21:59:08 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: freebsd-emulation@freebsd.org Subject: Linuxulator and VMware fix Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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