WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Xen

xen-devel

[Top] [All Lists]

Re: [Xen-devel] page ref/type count overflows

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] page ref/type count overflows
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: 2009年1月27日 10:24:14 +0000
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: 2009年1月27日 02:24:29 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <497EED2B.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmAaWa3nRf+0VeMkUegRKCBGfUbuQ==
Thread-topic: [Xen-devel] page ref/type count overflows
User-agent: Microsoft-Entourage/12.14.0.081024
On 27/01/2009 10:16, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
> Yes, I too realized that on my way home yesterday. The only thing I see as
> viable for consideration would be to remove the embedded spinlock again, and
> use the same bit-lock as x86-32 does.
Makes page_unlock() more expensive on x64. Don't know how much that matters.
> And of course I'd like to see the cpumask gone, but that's gonna be more
> tricky (if possible at all).
Given that page allocations tend to be bursty, we could tlbflush-check all
CPUs? Or make it a groups-of-CPUs mask? I suppose until we really care about
NR_CPUS > 64 it's not an important thing to get rid of anyhow.
>> And all my stuff is in, as of changeset 19093.
>
> Thanks! One thing though that puzzled me regarding c/s 19093: How can
> the mbz field have changed from being an overlay of u.inuse._domain to
> being one of count_info? And if this was indeed intended that way, then
> the comment prior to shadow_check_page_struct_offsets() should be
> updated accordingly.
It was deliberate because of how get_page() now works. Zero count_info is
properly how we determine 'ordinary' allocated pages from free pages and
shadow pages. I think keeping the owner field as mbz instead was a bit
fragile. Yes the comment needs updating.
> And shouldn't shadow's count field also be widened to BITS_PER_LONG-6?
Would be nice. Hopefully either Tim or Gianluca will see to that.
 -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: [Xen-devel] Re: lmbench lat_mmap slowdown with CONFIG_PARAVIRT , Jeremy Fitzhardinge
Next by Date: Re: [Xen-devel] Two shadow page tables for HVM , Tim Deegan
Previous by Thread: Re: [Xen-devel] page ref/type count overflows , Jan Beulich
Next by Thread: Re: [Xen-devel] page ref/type count overflows , Keir Fraser
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /