From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Sun, 8 Jun 2014 18:22:18 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e01419d922ef6af04fb565657 Subject: Re: [9fans] duppage Topicbox-Message-UUID: f7ded2b6-ead8-11e9-9d60-3106f5b1d025 --089e01419d922ef6af04fb565657 Content-Type: text/plain; charset=UTF-8 On 8 June 2014 15:53, erik quanstrom wrote: > i was experimenting a bit with cinap's version of dropping duppage, and for > the lame build the kernel tests there's quite a bit more i/o > that doesn't make any sense. duppage copied the page the wrong way round (used the image page and put another copy in). eliminating duppage simply copies the page from the image cache instead of using that page. there isn't any i/o in either case. --089e01419d922ef6af04fb565657 Content-Type: text/html; charset=UTF-8

On 8 June 2014 15:53, erik quanstrom <quanstro@quanstro.net> wrote:
i was experimenting a bit with cinap's version of dropping duppage, and for
the lame build the kernel tests there's quite a bit more i/o

that doesn't make any sense. duppage copied the page the wrong way round (used the image page and put another copy in).
eliminating duppage simply copies the page from the image cache instead of using that page. there isn't any i/o in either case.
--089e01419d922ef6af04fb565657--