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 -
----------------------------------------------------------------------
next prev parent 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