Date: Thu, 23 Jan 1997 21:05:49 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, syssgm@devetir.qld.gov.au Cc: dyson@freebsd.org, freebsd-current@freebsd.org Subject: Re: VM bogon? Was: Re: NIS breakage Message-ID: <199701231005.VAA26112@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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 Yes, 64K is the maximum block size, and copyout() is bypassed in many cases anyway, e.g., raw transfers are direct. >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. I hoped it was used for 64K cluster blocks, but the clustering routines don't seem to support that (fs's see only their own block size). >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 Oops. >>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. :-) Yes, there's nothing to stop context switching when copyin() blocks. I think this isn't a problem for the COW case (except for efficiency) because there will be a trap if the page becomes invalid. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701231005.VAA26112>