All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir.fraser@eu.citrix.com>
To: Jan Beulich <jbeulich@novell.com>,
	Joseph Cihula <joseph.cihula@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Cc: Dexuan Cui <dexuan.cui@intel.com>,
	Shane Wang <shane.wang@intel.com>,
	Yunhong Jiang <yunhong.jiang@intel.com>,
	Xiaowei Yang <xiaowei.yang@intel.com>,
	Liping Ke <liping.ke@intel.com>, Xin Li <xin.li@intel.com>
Subject: Re: RE: [RFC] fix xen_in_range()
Date: Fri, 24 Apr 2009 08:16:12 +0100	[thread overview]
Message-ID: <C61725CC.9654%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <49F180A8.76EA.0078.0@novell.com>

On 24/04/2009 08:04, "Jan Beulich" <jbeulich@novell.com> wrote:

> Also, after suggesting to use gb-pages when possible here I realized that
> it's probably a latent bug to map more space than was allocated - if the
> non-allocated-but-mapped pages happen to later get allocated to a domain,
> that domain may change the cacheability attributes of any of these pages,
> resulting in aliasing issues. I'll put together a patch for this, but it'll be
> a couple of days until I'll be able to do so.

I think we should shatter the superpage on demand. This would also be
required for superpage mappings of Xen itself: when we free initmem that
memory can now be allocated to a domain (now xenheap and domheap are merged
on x86/64).

An alternative might be to mark such partially-freed superpages as
Xenheap-only, and allocate them preferentially for Xenheap callers (i.e.,
alloc those pages first, then from the general heap).

 -- Keir

  reply	other threads:[~2009-04-24  7:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-22 23:53 [RFC] fix xen_in_range() Cihula, Joseph
2009-04-23  7:25 ` Keir Fraser
2009-04-23  7:58   ` Jan Beulich
2009-04-24  1:26   ` Cihula, Joseph
2009-04-24  7:04     ` Jan Beulich
2009-04-24  7:16       ` Keir Fraser [this message]
2009-04-24 23:14         ` Qing He
2009-04-24 23:20         ` [PATCH] iommu: fix unused percpu in xen_in_range() Qing He
2009-04-24 23:29       ` RE: [RFC] fix xen_in_range() Cihula, Joseph

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=C61725CC.9654%keir.fraser@eu.citrix.com \
    --to=keir.fraser@eu.citrix.com \
    --cc=dexuan.cui@intel.com \
    --cc=jbeulich@novell.com \
    --cc=joseph.cihula@intel.com \
    --cc=liping.ke@intel.com \
    --cc=shane.wang@intel.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xiaowei.yang@intel.com \
    --cc=xin.li@intel.com \
    --cc=yunhong.jiang@intel.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.