Date: Thu, 23 Jan 1997 14:01:57 +1000 From: Stephen McKay <syssgm@devetir.qld.gov.au> To: Bruce Evans <bde@zeta.org.au> Cc: dyson@freebsd.org, freebsd-current@freebsd.org, syssgm@devetir.qld.gov.au Subject: Re: VM bogon? Was: Re: NIS breakage Message-ID: <199701230401.OAA06542@troll.devetir.qld.gov.au>
next in thread | raw e-mail | index | archive | help
Bruce Evans <bde@zeta.org.au> wrote: >The validity checking for ordinary pages is fishy. Consider repeatedly >reading a 2*N MB block on an N MB system. After the first read, at >least half of the block should be user writable but swapped out. >Prefaulting it all in probably doesn't change this state. It just >increases swap activity. I think trapwrite() should only be called >when PG_W is clear. This is the only case where the i386 loses. In >particular, trapwrite() should not be called just to prefault pages >when PG_V is clear, PG_RW is set and PG_U is set. While this sounds interesting, I don't think it is applicable. Reading large blocks will not call copyout() with buffers bigger than main memory. As far a I can tell, 64kb is the maximum raw transfer (MAXPHYS, enforced by minphys()), meaning copyout() will access at most 17 pages. The typical transfer, I expect, would be an aligned 8kb fs block, accessing 2 pages. I don't think this would cause an actual increase in swap activity. Also, when PG_V is clear, the other flags have no meaning (actually, I think pmap.c zeros them all). Thus, we have to test for PG_V. The only valid combination is PG_U|PG_RW|PG_V. That is what is currently checked. I can't see any way to improve this at this low level. >Is it possible for a process to change the permissions for shared memory >while another process is accessing the memory in copyout()? Hmm. Can a checked-and-ok page become invalid while you are faulting in a subsequent page? Sounds ugly and possible. Oops, gotta go to a 3 hour meeting right now. You'll have to work this one out. :-) Stephen.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701230401.OAA06542>