From owner-freebsd-current Wed Jan 22 20:02:23 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA24571 for current-outgoing; Wed, 22 Jan 1997 20:02:23 -0800 (PST) Received: from bunyip.cc.uq.oz.au (daemon@bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA24564; Wed, 22 Jan 1997 20:02:17 -0800 (PST) Received: (from daemon@localhost) by bunyip.cc.uq.oz.au (8.8.4/8.8.4) id OAA19098; Thu, 23 Jan 1997 14:01:58 +1000 Received: from troll.devetir.qld.gov.au by ogre.devetir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with ESMTP id OAA18744; Thu, 23 Jan 1997 14:03:43 +1000 (EST) Received: from localhost (syssgm@localhost) by troll.devetir.qld.gov.au (8.8.5/8.8.5) with SMTP id OAA06542; Thu, 23 Jan 1997 14:01:57 +1000 (EST) Message-Id: <199701230401.OAA06542@troll.devetir.qld.gov.au> X-Authentication-Warning: troll.devetir.qld.gov.au: syssgm@localhost didn't use HELO protocol To: Bruce Evans cc: dyson@freebsd.org, freebsd-current@freebsd.org, syssgm@devetir.qld.gov.au Subject: Re: VM bogon? Was: Re: NIS breakage Date: Thu, 23 Jan 1997 14:01:57 +1000 From: Stephen McKay Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans 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.