From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Jiri Slaby <jirislaby@gmail.com>
Cc: Tejun Heo <htejun@gmail.com>, Ingo Molnar <mingo@elte.hu>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Vegard Nossum <vegard.nossum@gmail.com>
Subject: Re: __virt_addr_valid vs virtual percpu areas
Date: Wed, 04 Mar 2009 15:48:42 -0800 [thread overview]
Message-ID: <49AF135A.4060604@goop.org> (raw)
In-Reply-To: <49AF0C81.7060908@gmail.com>
Jiri Slaby wrote:
> It's not (in the meaning of virt_* functions), but while booting we
> don't have variables used in VMALLOC_START and VMALLOC_END ready for
> use on i386.
>
> Maybe we can introduce more clever method/state which would say: hey,
> vmalloc framework is up and running. And use instead (system_state !=
> SYSTEM_BOOTING) hack.
Yeah, I pieced that together. I'm just testing a patch with a specific
__vmalloc_start_set flag to test.
>> This is biting me because I need to translate percpu addresses
>> to pfns, but I only bother doing the full pagetable walk if
>> virt_addr_valid() is false (otherwise I just use __pa()).
>
> Do you need to bother also with vmalloc space?
percpu data gets mapped into the vmalloc region now (when using 4k page
mappings, at least).
>> Removing this test doesn't seem to harm anything at first glance. Is
>> this OK to do in general (and can we quietly set fire to system_state
>> while we're about it)?
>
> I wouldn't do that, since vmalloc addr is not virt addr, again in the
> meaning of virt_* functions. And the function wouldn't do the right
> thing, at least in the RUNNING state anymore.
OK.
J
prev parent reply other threads:[~2009-03-04 23:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-04 22:57 __virt_addr_valid vs virtual percpu areas Jeremy Fitzhardinge
2009-03-04 23:19 ` Jiri Slaby
2009-03-04 23:48 ` Jeremy Fitzhardinge [this message]
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=49AF135A.4060604@goop.org \
--to=jeremy@goop.org \
--cc=htejun@gmail.com \
--cc=jirislaby@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=vegard.nossum@gmail.com \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.