From: "Jared Hulbert" <jaredeh@gmail.com>
To: carsteno@de.ibm.com
Cc: "Nick Piggin" <nickpiggin@yahoo.com.au>,
"Andrew Morton" <akpm@linux-foundation.org>,
richard.griffiths@windriver.com,
"Richard Griffiths" <res07ml0@verizon.net>,
Linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
Date: Fri, 15 Jun 2007 14:46:07 -0700 [thread overview]
Message-ID: <6934efce0706151446o44526edbn9e2ef993e2c1d3be@mail.gmail.com> (raw)
In-Reply-To: <467299F5.3070704@de.ibm.com>
On 6/15/07, Carsten Otte <cotte@de.ibm.com> wrote:
> Nick Piggin wrote:
> > Carsten Otte wrote:
> >> The current xip stack relies on having struct page behind the memory
> >> segment. This causes few impact on memory management, but occupies
> >> some more memory. The cramfs patch chose to modify copy on write in
> >> order to deal with vmas that don't have struct page behind.
> >> So far, Hugh and Linus have shown strong opposition against copy on
> >> write with no struct page behind. If this implementation is acceptable
> >> to the them, it seems preferable to me over wasting memory. The xip
> >> stack should be modified to use this vma flag in that case.
> >
> > I would rather not :P
> >
> > We can copy on write without a struct page behind the source today, no?
> > What is insufficient for the XIP code with the current COW?
>
> I've looked at the -mm version of mm/memory.c today, with intend to
> try out VM_PFNMAP for our xip mappings and replace nopage() with fault().
> The thing is, I believe it does'nt work for us:
> * The way we recognize those mappings is through the rules set up
> * by "remap_pfn_range()": the vma will have the VM_PFNMAP bit set,
> * and the vm_pgoff will point to the first PFN mapped: thus every
> * page that is a raw mapping will always honor the rule
> *
> * pfn_of_page == vma->vm_pgoff + ((addr - vma->vm_start) >>
> PAGE_SHIFT)
>
> This is, as far as I can tell, not true for our xip mappings. Ext2 may
> spread the physical pages behind a given file all over its media. That
> means, that the pfns of the pages that form a vma may be more or less
> random rather than contiguous. The common memory management code
> cannot tell whether or not a given page has been COW'ed.
> Did I miss something?
I agree, the conditions imposed by the remap_pfn_range() don't work.
next prev parent reply other threads:[~2007-06-15 21:46 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-22 22:09 [PATCH 2.6.21] cramfs: add cramfs Linear XIP Richard Griffiths
2007-05-22 22:49 ` Andrew Morton
2007-05-22 22:58 ` Richard Griffiths (wrs)
2007-05-23 7:51 ` Carsten Otte
2007-05-23 15:25 ` Richard Griffiths (wrs)
2007-05-24 6:46 ` Carsten Otte
2007-05-23 17:21 ` Jared Hulbert
2007-05-24 6:57 ` Carsten Otte
2007-05-29 5:10 ` Nick Piggin
2007-06-02 0:48 ` Jared Hulbert
2007-06-02 8:42 ` Nick Piggin
2007-06-04 13:32 ` Carsten Otte
2007-06-06 11:13 ` Jared Hulbert
2007-06-06 11:33 ` Christoph Hellwig
2007-06-06 15:17 ` Richard Griffiths
2007-06-06 15:50 ` Christoph Hellwig
2007-06-06 16:09 ` Jared Hulbert
2007-06-06 16:07 ` Jared Hulbert
2007-06-06 16:16 ` Christoph Hellwig
2007-06-06 18:26 ` Jared Hulbert
2007-06-07 19:37 ` Christoph Hellwig
2007-06-07 19:40 ` Christoph Hellwig
2007-06-07 20:27 ` Jared Hulbert
2007-06-08 7:39 ` Carsten Otte
2007-06-07 21:11 ` Jared Hulbert
2007-06-07 21:15 ` Christoph Hellwig
2007-06-07 22:59 ` Jared Hulbert
2007-06-08 13:19 ` Jörn Engel
2007-06-08 13:10 ` Jörn Engel
2007-06-06 16:15 ` Carsten Otte
2007-06-06 16:23 ` Christoph Hellwig
2007-06-06 18:40 ` Jared Hulbert
2007-06-06 22:59 ` Matt Mackall
2007-06-07 17:07 ` Carsten Otte
2007-06-07 19:38 ` Christoph Hellwig
2007-06-07 20:34 ` Jared Hulbert
2007-06-08 7:28 ` Christoph Hellwig
2007-06-08 16:02 ` Jared Hulbert
2007-06-08 7:17 ` Carsten Otte
2007-06-08 7:26 ` Christoph Hellwig
2007-06-08 7:50 ` Carsten Otte
2007-06-08 7:57 ` Christoph Hellwig
2007-06-08 7:59 ` Carsten Otte
2007-06-08 8:04 ` Christoph Hellwig
2007-06-08 16:05 ` Jared Hulbert
2007-06-08 16:09 ` Christoph Hellwig
2007-06-08 16:11 ` Jared Hulbert
2007-06-08 16:15 ` Christoph Hellwig
2007-06-08 17:51 ` Jörn Engel
2007-06-08 19:04 ` Carsten Otte
2007-06-08 19:06 ` Carsten Otte
2007-06-08 19:36 ` Jörn Engel
2007-06-09 7:55 ` Carsten Otte
2007-06-09 10:37 ` Jörn Engel
2007-06-08 23:02 ` Jared Hulbert
2007-06-07 21:19 ` Jared Hulbert
2007-06-06 12:05 ` Carsten Otte
2007-06-06 19:01 ` Jared Hulbert
2007-06-07 1:00 ` Justin Treon
2007-06-13 0:11 ` Jared Hulbert
2007-06-14 13:57 ` Carsten Otte
2007-06-14 16:53 ` Jared Hulbert
2007-06-15 9:22 ` Carsten Otte
2007-06-15 11:49 ` Heiko Carstens
2007-06-15 17:30 ` Jared Hulbert
2007-06-18 7:38 ` Carsten Otte
2007-06-15 13:53 ` Carsten Otte
2007-06-15 21:46 ` Jared Hulbert [this message]
2007-05-23 8:21 ` Alistair John Strachan
2007-05-24 20:22 ` Jared Hulbert
2007-05-24 20:52 ` Richard Griffiths
2007-05-24 21:21 ` Jared Hulbert
[not found] <337240.79058.qm@web59309.mail.re1.yahoo.com>
2007-06-09 8:09 ` Carsten Otte
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=6934efce0706151446o44526edbn9e2ef993e2c1d3be@mail.gmail.com \
--to=jaredeh@gmail.com \
--cc=Linux-kernel@vger.kernel.org \
--cc=akpm@linux-foundation.org \
--cc=carsteno@de.ibm.com \
--cc=nickpiggin@yahoo.com.au \
--cc=res07ml0@verizon.net \
--cc=richard.griffiths@windriver.com \
/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;
as well as URLs for NNTP newsgroup(s).