public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rick Stevens <rstevens@vitalstream.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Note describing poor dcache utilization under high memory pressure
Date: Mon, 28 Jan 2002 13:33:14 -0800	[thread overview]
Message-ID: <3C55C39A.8040203@vitalstream.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0201281005480.1609-100000@penguin.transmeta.com> <E16VHy5-0000Bz-00@starship.berlin>

Daniel Phillips wrote:
[snip]

> I've been a little slow to 'publish' this on lkml because I wanted a working 
> prototype first, as proof of concept.  My efforts to dragoon one or more of 
> the notably capable kernelnewbies crowd into coding it haven't been 
> particularly successful, perhaps due to the opacity of the code in question 
> (pgtable.h et al).  So I've begun coding it myself, and it's rather slow 
> going, again because of the opacity of the code.  Oh, and the difficult 
> nature of the problem itself, since it requires understanding pretty much all 
> of Unix memory management semantics first, including the bizarre (and useful) 
> properties of process forking.
> 
> The good news is, the code changes required do fit very cleanly into the 
> current design.  Changes are required in three places I've identified so far:
> 
>   copy_page_range
>     Intead of copying the page tables, just increment their use counts
> 
>   zap_page_range:
>     If a page table is shared according to its use count, just decrement
>     the use count and otherwise leave it alone.
> 
>   handle_mm_fault:
>     If a page table is shared according to its use count and the faulting 
>     instruction is a write, allocate a new page table and do the work that 
>     would have normally been done by copy_page_range at fork time.
>     Decrement the use count of the (perhaps formerly) shared page table.


Perhaps I'm missing this, but I read that as the child gets a reference
to the parent's memory.  If the child attempts a write, then new memory
is allocated, data copied and the write occurs to this new memory.  As
I read this, it's only invoked on a child write.

Would this not leave a hole where the parent could write and, since the
child shares that memory, the new data would be read by the child?  Sort
of a hidden shm segment?  If so, I think we've got problems brewing.
Now, if a parent write causes the same behaviour as a child write, then
my point is moot.

Could you clarify this for me?  I'm probably way off base here.

----------------------------------------------------------------------
- Rick Stevens, SSE, VitalStream, Inc.      rstevens@vitalstream.com -
- 949-743-2010 (Voice)                    http://www.vitalstream.com -
-                                                                    -
-           grep me no patterns and I'll tell you no lines           -
----------------------------------------------------------------------


  reply	other threads:[~2002-01-28 21:33 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-28 17:13 Note describing poor dcache utilization under high memory pressure Josh MacDonald
2002-01-28 17:39 ` Linus Torvalds
2002-01-28 18:01   ` Rik van Riel
2002-01-28 18:21     ` Linus Torvalds
2002-01-28 18:37       ` Rik van Riel
2002-01-28 19:28         ` William Lee Irwin III
2002-01-28 20:01       ` Daniel Phillips
2002-01-28 21:33         ` Rick Stevens [this message]
2002-01-28 21:43           ` Rik van Riel
2002-01-28 22:00             ` Rick Stevens
2002-01-28 22:43               ` Daniel Phillips
2002-01-28 23:06                 ` Rick Stevens
2002-01-28 23:51                   ` [OT] " jepler
2002-01-29  2:30                     ` IPmonger
2002-01-29 12:02                       ` Karl & Betty Schendel
2002-01-28 22:26             ` Daniel Phillips
2002-01-28 22:34           ` Brian Gerst
2002-01-28 23:08             ` Daniel Phillips
2002-01-28 22:39           ` Daniel Phillips
2002-01-28 23:12             ` Rick Stevens
2002-01-28 23:27               ` Daniel Phillips
2002-01-28 22:01         ` Momchil Velikov
2002-01-28 22:19           ` Daniel Phillips
2002-01-29  1:29         ` Oliver Xymoron
2002-01-29  1:37           ` [reiserfs-list] " Valdis.Kletnieks
2002-01-29  1:45           ` Daniel Phillips
2002-01-29  8:39           ` Momchil Velikov
2002-01-29  8:55             ` Daniel Phillips
2002-01-29  9:20               ` William Lee Irwin III
2002-01-29  9:55                 ` Daniel Phillips
2002-01-29 10:18                 ` Momchil Velikov
2002-01-29 19:55                   ` William Lee Irwin III
2002-01-29 20:08                     ` Linus Torvalds
2002-01-29 20:39                       ` William Lee Irwin III
2002-01-29 20:49                         ` Linus Torvalds
2002-01-29 21:01                           ` William Lee Irwin III
2002-01-29  9:20               ` Momchil Velikov
2002-01-29 10:27                 ` Daniel Phillips
2002-01-29 11:54                 ` Helge Hafting
2002-01-29 12:33                   ` Daniel Phillips
2002-01-30  9:07                     ` Horst von Brand
2002-01-30 10:55                       ` Daniel Phillips
2002-01-30 14:46                         ` Rik van Riel
2002-01-30 14:59                           ` Daniel Phillips
2002-01-30 15:54                             ` Rik van Riel
2002-01-30 16:34                               ` Daniel Phillips
2002-01-29 10:59           ` Rik van Riel
2002-01-29 11:28             ` Daniel Phillips
2002-01-29 11:38               ` Rik van Riel
2002-01-29 12:01                 ` Daniel Phillips
2002-01-29 16:57             ` Oliver Xymoron
2002-01-29 17:25               ` Rik van Riel
2002-01-29 20:48                 ` Daniel Phillips
2002-01-29 21:00                   ` Oliver Xymoron
2002-01-29 21:08                     ` Linus Torvalds
2002-01-29 21:13                       ` Oliver Xymoron
2002-01-29 21:50                         ` Linus Torvalds
2002-01-29 22:02                           ` Oliver Xymoron
2002-01-29 22:10                             ` Linus Torvalds
2002-01-29 22:53                           ` Daniel Phillips
2002-01-29 22:53                     ` Daniel Phillips
2002-01-29 23:02                       ` Oliver Xymoron
2002-01-29 23:21                         ` Daniel Phillips
2002-01-28 19:25   ` [reiserfs-dev] " Hans Reiser
2002-01-28 23:52     ` Daniel Phillips
2002-01-29  0:16       ` Hans Reiser
2002-01-29  0:30         ` Alexander Viro
2002-01-29 10:46           ` Hans Reiser
2002-01-29 14:50             ` Chris Mason
2002-01-29 21:10               ` Hans Reiser
2002-01-30  7:11                 ` Oliver Xymoron
2002-01-30  9:57                   ` Hans Reiser
2002-01-29 17:28           ` Josh MacDonald
2002-01-29 18:44             ` [reiserfs-list] " Andreas Dilger
2002-01-29 19:55               ` Andrew Morton
2002-01-30  7:17                 ` Oliver Xymoron
2002-01-30  7:32                   ` [reiserfs-list] Re: [reiserfs-dev] Re: Note describing poordcache " Andrew Morton
2002-01-30  7:52                     ` Oliver Xymoron
2002-01-30 10:03                     ` Hans Reiser
2002-01-30 10:07             ` [reiserfs-dev] Re: Note describing poor dcache " Horst von Brand
2002-01-29 18:29           ` Horst von Brand
2002-01-29  0:51         ` Daniel Phillips
2002-01-29  1:32           ` Daniel Phillips
2002-01-28 22:46   ` Alex Bligh - linux-kernel
2002-01-29 17:27   ` Josh MacDonald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C55C39A.8040203@vitalstream.com \
    --to=rstevens@vitalstream.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox