Re: page ref/type count overflows

["Jan Beulich" <jbeulich@novell.com>]

>>> Keir Fraser <keir.fraser@eu.citrix.com> 26.01.09 18:01 >>>
>On 26/01/2009 14:54, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:
>
>>> The count_info one only, or are you also intending to change _domain?
>>> With struct page_info pretty large already, I'd want to avoid growing it
>>> needlessly.
>> 
>> I'm going to change both and do it the easy way, growing the structure from
>> 40 to 48 bytes. You can shrink it again with the tricks you describe if
>> you're keen. I'm not sure how ugly the list stuff would end up, which would
>> be my main concern, but I suppose you can hide it behind list.h-style
>> macros. I don't see there's much duplication of effort to phase the work
>> like this.
>
>By the way, unless you can see some really clever way to shrink page_info to
>32 bytes then I think it is only worth doing compression tricks on the
>list_head field, to save 8 bytes (struct becomes 40 bytes). Compressing the
>domain field won't get you down to another multiple-of-eight size. It may be
>a trick to keep in mind for future though...

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.

And of course I'd like to see the cpumask gone, but that's gonna be more
tricky (if possible at all).

>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.

And shouldn't shadow's count field also be widened to BITS_PER_LONG-6?

Jan