[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] page ref/type count overflows
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |