From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: page ref/type count overflows Date: Tue, 27 Jan 2009 10:16:59 +0000 Message-ID: <497EED2B.76E4.0078.0@novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 26.01.09 18:01 >>> >On 26/01/2009 14:54, "Keir Fraser" 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. >>=20 >> 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