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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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