From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"Ian Jackson" <Ian.Jackson@eu.citrix.com>,
"Keir Fraser" <Keir.Fraser@eu.citrix.com>
Subject: Re: dom0 pvops crash
Date: Wed, 27 Jan 2010 11:34:54 -0800 [thread overview]
Message-ID: <4B60955E.4080308@goop.org> (raw)
In-Reply-To: <1264619930.2392.248.camel@localhost.localdomain>
On 01/27/2010 11:18 AM, Ian Campbell wrote:
>> That's a thought. It could be generally useful too; highpte should only
>> be used in extreme circumstances (to prevent ptes from filling most of
>> lowmem), not on every system with highmem. IOW use a generic flag
>> rather than make it explicitly Xen-related, then we can set that flag.
>>
> I think this is the most plausible idea. Need to think about what
> criteria would be used to set the flag on native, simply raw RAM size?
> i.e. you wouldn't use HIGHPTE on a 4G system, even if CONFIG_HIGHPTE is
> enabled, but where would the cut-off be?
>
> Rather than a flag I guess I'd make a pte_gfp variable which could be
> modified to suit.
>
Well, you could try heuristicing it up, but I suspect a simpler approach
is just a variable which is enabled by command line and/or config
option. HIGHPTE is an arch-independent concept, but the policy for
defaulting it is arch-specific; on x86 it should almost always be off.
>> Or we could just put a big fat config dependency in.
>>
> I'd imagine that seemingly random "depends !XEN" would be unpopular
> upstream.
>
I was thinking the other way around; Xen depends on !HIGHPTE. But a
runtime switch would be just as good.
J
next prev parent reply other threads:[~2010-01-27 19:34 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-25 16:29 dom0 pvops crash Ian Jackson
2010-01-25 17:10 ` Keir Fraser
2010-01-25 17:28 ` Ian Jackson
2010-01-25 17:54 ` Pasi Kärkkäinen
2010-01-25 18:03 ` Ian Jackson
2010-01-25 18:57 ` Keir Fraser
2010-01-25 19:00 ` Jeremy Fitzhardinge
2010-01-25 19:31 ` Keir Fraser
2010-01-25 20:02 ` Jeremy Fitzhardinge
2010-01-26 11:53 ` Jan Beulich
2010-01-27 17:26 ` Ian Campbell
2010-01-27 18:50 ` Jeremy Fitzhardinge
2010-01-27 19:18 ` Ian Campbell
2010-01-27 19:34 ` Jeremy Fitzhardinge [this message]
2010-01-27 20:03 ` Pasi Kärkkäinen
2010-01-27 20:07 ` Jeremy Fitzhardinge
2010-02-07 19:35 ` Pasi Kärkkäinen
2010-02-07 21:42 ` Ian Campbell
2010-02-07 22:22 ` Daniel Stodden
2010-02-08 7:41 ` Pasi Kärkkäinen
2010-02-08 7:47 ` Ian Campbell
2010-02-08 8:06 ` Pasi Kärkkäinen
2010-02-08 8:50 ` Ian Campbell
2010-02-08 8:57 ` Pasi Kärkkäinen
2010-02-08 12:57 ` Xen pvops kernel CONFIG_HIGHPTE race/crash Pasi Kärkkäinen
2010-02-08 17:34 ` Pasi Kärkkäinen
2010-02-09 9:14 ` Ian Campbell
2010-01-25 18:18 ` dom0 pvops crash Ian Pratt
2010-01-25 18:26 ` Ian Campbell
2010-02-02 10:23 ` Pasi Kärkkäinen
2010-02-02 10:31 ` Ian Campbell
2010-02-02 10:45 ` Pasi Kärkkäinen
2010-01-25 17:11 ` Pasi Kärkkäinen
2010-01-25 17:30 ` Ian Jackson
2010-01-25 17:42 ` Pasi Kärkkäinen
2010-01-26 13:45 ` Ian Jackson
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=4B60955E.4080308@goop.org \
--to=jeremy@goop.org \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=Keir.Fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.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 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.