From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: MADV_DONTNEED References: <20000322184357.C7271@pcep-jamie.cern.ch> <20000322234115.B31795@pcep-jamie.cern.ch> From: James Antill Reply-To: Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 23 Mar 2000 14:13:12 -0500 In-Reply-To: Jamie Lokier's message of "Wed, 22 Mar 2000 23:41:15 +0100" Message-ID: Sender: owner-linux-mm@kvack.org Return-Path: To: Jamie Lokier Cc: Chuck Lever , linux-mm@kvack.org List-ID: > Chuck Lever wrote: > > > If I knew what msync(MS_INVALIDATE) did I could think about this! :-) > > > But the msync documentation is unhelpful and possibly misleading. > > > > well, the doc's accurate, as far as i can tell. but my use of it is a > > side-effect of the behavior described in the man page. > > "MS_INVALIDATE asks to invalidate other mappings of the > same file (so that they can be updated with the fresh val- > ues just written)." > > Oh I see. It means the locally modified but in principle shared mapping > is copied back to the underlying object. For a page aligned mapping > that shouldn't need to do anything. > > Since the MS_INVALIDATE code doesn't modify other ptes, we must assume > the other mappings are all page aligned or they wouldn't see the > update. > > So why does MS_INVALIDATE have any code? :-) I've used this in Solaris when mmap()'ing over NFS. Ie. You'd msync(MS_SYNC) on the NFS writer, and msync(MS_INVALIDATE) on the readers. The Linux documentation I have is the same as Jamie's and says _other_ mappings, but maybe that's just a typo (I'm pretty sure INVALIDATE on solaris guaranteed that your mapping was invalidas well). -- James Antill -- james@and.org "If we can't keep this sort of thing out of the kernel, we might as well pack it up and go run Solaris." -- Larry McVoy. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux.eu.org/Linux-MM/