From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 6 13:40:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEB1237B401 for ; Wed, 6 Aug 2003 13:40:22 -0700 (PDT) Received: from bricore.com (adsl-64-168-71-68.dsl.snfc21.pacbell.net [64.168.71.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBD4443F93 for ; Wed, 6 Aug 2003 13:40:21 -0700 (PDT) (envelope-from lchen@briontech.com) Received: from lchenpc (lchen-pc.bricore.com [192.168.1.130]) (authenticated bits=0) by bricore.com (8.12.6/8.12.6) with ESMTP id h76KeIv2025865; Wed, 6 Aug 2003 13:40:18 -0700 (PDT) (envelope-from lchen@briontech.com) From: "Luoqi Chen" To: "Ed L Cashin" , Date: Wed, 6 Aug 2003 13:45:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <87he4uzr1z.fsf@uga.edu> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Subject: RE: COW and mprotect on non-shared memory X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2003 20:40:23 -0000 > For that reason, when you mprotect an area of non-shared, anonymous > memory to no access and then back to writable, Linux has no way of > knowing that the memory wasn't set for COW before you make it > unwritable. It goes ahead and makes all the pages in the area COW. > > That means that if I do this: > > for (i = 0; i < n; ++i) { > assert(!mprotect(p, pgsiz, PROT_NONE)); > assert(!mprotect(p, pgsiz, PROT_READ|PROT_WRITE|PROT_EXEC)); > p[i] = i & 0xff; > } > > ... I get n minor page faults! Pretty amazing, but I guess they > figured nobody does that. > > More surprising is that the same test program has the same behavior on > FreeBSD. (At least, the "/usr/bin/time -l ..." output shows the > number of page reclaims increasing at the same rate that I increase > the value of n in the loop.) > > I thought that in FreeBSD any COW area would have its own vm_map_entry > with the MAP_ENTRY_COW bit set. That way, you could run this test > without any minor faults at all. Now I suspect I was incorrect. > Could anyone help clarify the situation for me? > > Thanks. > > -- > --Ed L Cashin | PGP public key: > ecashin@uga.edu | http://noserose.net/e/pgp/ > The first mprotect() removes the physical mapping from the page table, the second mprotect() doesn't do anything because the mapping isn't there. So when the page is accessed, a fault is needed to insert the mapping back to the page table. -lq