This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue Apr 23 20:22:00 2024 Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by herbie.ucs.indiana.edu (8.7.5/8.6.12) with ESMTP id LAA25578 for ; Wed, 8 Jan 1997 11:53:53 -0500 (EST) Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66195-30176>; Wed, 8 Jan 1997 18:54:21 +0200 Received: by vger.rutgers.edu id <213159-26715>; Wed, 8 Jan 1997 11:38:42 -0500 Date: Wed, 8 Jan 1997 12:42:29 -0400 (AST) From: William Burrow To: linux-kernel@vger.rutgers.edu Subject: Zero page Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/REPORT; REPORT-TYPE=delivery-status; BOUNDARY="A100B2E39.852682997=_/vger.rutgers.edu" Content-ID: Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --A100B2E39.852682997=_/vger.rutgers.edu Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Messages sent as attachments due to my error. --A100B2E39.852682997=_/vger.rutgers.edu Content-Type: MESSAGE/DELIVERY-STATUS Content-ID: Reporting-MTA: dns; vger.rutgers.edu Arrival-Date: Tue, 7 Jan 1997 19:23:11 -0500 Original-Recipient: rfc822;linux-devel@vger.rutgers.edu Final-Recipient: X-LOCAL;linux-devel Action: failed Status: 5.1.1 (User does not exist) Diagnostic-Code: x-local; 550 (User does not exist) --A100B2E39.852682997=_/vger.rutgers.edu Content-Type: MESSAGE/RFC822 Content-ID: Received: from unb.ca ([131.202.3.20]) by vger.rutgers.edu with ESMTP id <213015-8004>; Tue, 7 Jan 1997 19:23:13 -0500 Received: (from aa126@fan1.fan.nb.ca [131.202.9.99]) by unb.ca (8.7.6/961016-08:40) id UAA12039; Tue, 7 Jan 1997 20:28:45 -0400 (AST) Received: by fan1.fan.nb.ca (8.6.12/951109-23:05) id UAA14688; Tue, 7 Jan 1997 20:28:43 -0400 Date: Tue, 7 Jan 1997 20:28:43 -0400 (AST) From: William Burrow To: Patrick Schaaf cc: linux-devel@vger.rutgers.edu Subject: Re: Using the zero mapped page In-Reply-To: <199701072127.WAA01684@nano.saarlink.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 7 Jan 1997, Patrick Schaaf wrote: > In linux.dev.kernel you write: > > >It occurs to me however, that perhaps the kernel would receive a page > >fault everytime such a zero value assignment might occur, and further, > >the kernel might not be aware of the value that is going to be put into > >the page. The former might be a severe performance penalty (is it?) and > >the latter would forbid this from happening. > > The latter forbids this from happening. You'd have to disassemble the > faulting code to find out which value was to be written. That is as I suspect. > Your proposal does not make sense anyway - the zero page is one physical It makes profound sense if we are to avoid writing to a slow memory medium, the disk. See the explanation below. > page that is usually mapped into a few 10-100 page table slots in > arbitrary processes - reallocating it to one process that just writes > a zero to it would need to scan big kbytes of pagetables to patch > that sharing away... That is not what is being proposed. In the first case given, I would suggest just not writing the zero at all (especially into a page full of only zeroes). Why bother, it affects nothing. In the second case, it is suggested not writing pages that are *all* zero values to the swap device. Do you follow? When a write to the zero page occurs, the usual page is still created as normal, because as has already been pointed out the kernel cannot know what goes into the page without considerable more work. Yet when it comes time to swap out that page, the page is simply removed from memory and the zero page is referenced again instead. Does this sound like a good trick now? You get 4K more memory for free just for the effort of checking if the page is indeed all zeroes. In another message, various Intel specific timings wrt to this technique of avoiding writing zero filled pages are given. At first glance it seems a big win over using the disk to store zero filled pages. It would be convenient if anybody could come up with reasons why not when it looks so good on paper and solves the problem of swapping trivial pages of data, a seemingly useless exercise. In a quick summary: one might take an order or two less time checking the page than reading from or writing to disk, depending on the disk and CPU. Someone suggested to me that a system running X, httpd and few users might swap about 6-10% zero filled pages. This is of more interest to users doing calculations with large sparse matrices or other computations with large zero filled buffers than home users. I am poking at relevent kernel files to see what is going on, but any pointers would be strongly appreciated. -- William Burrow -- Fredericton Area Network, New Brunswick, Canada Copyright 1997 William Burrow This line left intentionally blank. And the one below it. --A100B2E39.852682997=_/vger.rutgers.edu--