From: Jes Sorensen <jes@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: Robin Holt <holt@sgi.com>,
linux-kernel@vger.kernel.org,
Nick Piggin <nickpiggin@yahoo.com.au>,
Hugh Dickins <hugh@veritas.com>, Carsten Otte <cotte@de.ibm.com>,
bjorn_helgaas@hp.com
Subject: Re: [patch] do_no_pfn
Date: Wed, 21 Jun 2006 11:50:53 +0200 [thread overview]
Message-ID: <4499167D.1040308@sgi.com> (raw)
In-Reply-To: <200606201135.53824.ak@suse.de>
Andi Kleen wrote:
>> One struct page for a random single page here, another for a single
>> random page there. And the risk that someone will start walking the
>> pages and dereference and cause data corruption. As explained before,
>> it's a bad idea.
>
> Note sure what your point is. Why should they cause memory corruption?
>
> Allowing struct page less VM is worse. If you add that then people
> will use it for other stuff, and eventually we got a two class
> VM. All not very good.
Special treatment of the pages are required. In particular they *must*
be referenced in uncached mode. If something derefences the struct page
in cached mode and the official user of the page does it correctly in
uncached mode one risks memory corruption. It's worse than that in fact
it has to be a full granule of pages that isn't touched like this.
But as Robin pointed out, there just is no real benefit to having a
struct page behind it.
Cheers,
Jes
next prev parent reply other threads:[~2006-06-21 9:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-19 9:19 [patch] do_no_pfn Jes Sorensen
2006-06-19 13:06 ` Andi Kleen
2006-06-19 22:49 ` Robin Holt
2006-06-20 8:01 ` Jes Sorensen
2006-06-20 8:13 ` Andi Kleen
2006-06-20 8:40 ` Jes Sorensen
2006-06-20 8:48 ` Andi Kleen
2006-06-20 9:12 ` Jes Sorensen
2006-06-20 9:35 ` Andi Kleen
2006-06-20 11:02 ` Robin Holt
2006-06-21 9:50 ` Jes Sorensen [this message]
2006-06-20 16:03 ` Bjorn Helgaas
2006-06-21 7:38 ` Carsten Otte
2006-06-20 8:58 ` Carsten Otte
2006-06-27 12:46 ` [patch] do_no_pfn - against latest git Jes Sorensen
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=4499167D.1040308@sgi.com \
--to=jes@sgi.com \
--cc=ak@suse.de \
--cc=bjorn_helgaas@hp.com \
--cc=cotte@de.ibm.com \
--cc=holt@sgi.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
/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