From: Mike Kravetz <kravetz@us.ibm.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Joel Schopp <jschopp@austin.ibm.com>,
linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Use of __pa() with CONFIG_NONLINEAR
Date: Wed, 28 Jul 2004 11:16:45 -0700 [thread overview]
Message-ID: <20040728181645.GA13758@w-mikek2.beaverton.ibm.com> (raw)
In-Reply-To: <1090965630.15847.575.camel@nighthawk>
On Tue, Jul 27, 2004 at 03:00:30PM -0700, Dave Hansen wrote:
> So, for CONFIG_NONLINEAR, we introduce a new indirection layer for
> virtual to physical conversions (and the inverse as well). Our
> implementation uses some data structures to do this (patch is here:
> http://lwn.net/Articles/79124/), and the side-effect is that we can't
> use __pa() or __va() until after the initialization has run, which is
> early in setup_arch().
>
> But, there are quite a few things that obviously need physical addresses
> earlier than that, such as cr3 initialization at compile-time. So, in
> Dave McCracken's patch, he introduced a new function: __boot_pa() that
> does what the old __pa() did.
>
As Joel Stated in another note, I think documentation/comments is a must.
My 'guess' is that anyone writing early init code is going to have a
difficult time here. As you stated the memsection initialization would
happen in setup_arch(). For arch independent code this makes it pretty
straight forward as everything run before the setup_arch() can use
the old/offset method of calculating physical addresses and everything
after can use the new method. However, the arch specific initialization
code is more difficult as it depends on where the call paths are relative
to setup/alloc_memsections within setup_arch().
When I was trying to get nonlinear working on a specific architecture,
I made the routines go through 'pointer to functions' and had the memsections
initialization code modify the pointer after initialization was complete.
In this way, I got the nonlinear code code up and working without changing
all the early __pa/__va calls. Obviously, this is a hack that should not
be used as it introduces another level of indirection to performance
critical code. However, it was easy and saved me the effort of all that
code inspection. :)
--
Mike
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-07-28 18:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-27 22:00 Dave Hansen
2004-07-28 16:20 ` Joel Schopp
2004-07-28 18:16 ` Mike Kravetz [this message]
2004-07-28 19:47 ` Martin J. Bligh
2004-07-28 20:13 ` Dave Hansen
2004-07-28 20:15 ` Martin J. Bligh
2004-07-28 20:23 ` Dave Hansen
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=20040728181645.GA13758@w-mikek2.beaverton.ibm.com \
--to=kravetz@us.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=jschopp@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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