Date: Tue, 28 Jul 1998 00:48:24 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: current@FreeBSD.ORG Subject: Diagnostic for those with MMAP problems... Message-ID: <199807280048.RAA16684@usr01.primenet.com>
next in thread | raw e-mail | index | archive | help
I would like someone who can readily repeat these problems to try one or both of the following, and see what happens. I realize that the first is probably impractical for those repeating the glitch using INN, but it's worth mentioning. 1) Rebuild your kernel with NO_SWAPPING. This will help determine if this is a vnode pager problem, a generic pager problem, or a swap pager problem (by eliminating or indicting the swap pager). I realize that this implies you have a lot of RAM... 2) Rebuild the software using MMAP; add "PROT_WRITE" to the protection request. The logic behind this has to do with some suspicious partial page code which is XXX'ed in the comments in the VM sources, and for the COW code, which might be theoretically capable of leaking an alias (in other words, it selects a different code path that should match the write code path better than the fault code path). Basically, if this one fixes the symptom, it'll be bad in a different way because it will mean that the alias is recognized, and the file write ends up COW'ing the page. Note that msync() on FreeBSD is a kludge way of dealing with file extension of a backing object, and that a unified VM and buffer cache shouldn't need it. It's only use, really, is for transactioning, allowing user space code to force a commit of dirty data to the backing object. This should mean that adding PROT_WRITE will *NOT* require you to call msync(), contrary to the INN documentation. I would do this, but I don't really have a sandbox system I can use to run my simplified churning tests at this time, and I can't risk a non-sandbox system. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807280048.RAA16684>