--A100B2E39.852682997=_/vger.rutgers.edu
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.SOL.3.91.970108124122.9154D@fan1.fan.nb.ca>
Messages sent as attachments due to my error.
--A100B2E39.852682997=_/vger.rutgers.edu
Content-Type: MESSAGE/DELIVERY-STATUS
Content-ID: <Pine.SOL.3.91.970108124122.9154E@fan1.fan.nb.ca>
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: <Pine.SOL.3.91.970108124122.9154F@fan1.fan.nb.ca>
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 <aa126@fan.nb.ca>
To: Patrick Schaaf <bof@saarlink.de>
cc: linux-devel@vger.rutgers.edu
Subject: Re: Using the zero mapped page
In-Reply-To: <199701072127.WAA01684@nano.saarlink.de>
Message-ID: <Pine.SOL.3.91.970107200305.12640D-100000@fan1.fan.nb.ca>
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--