From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: page_alloc query Date: Wed, 07 Mar 2007 09:18:02 +0000 Message-ID: <45EE915A.76E4.0078.0@novell.com> References: <45EDE6D8.2040505@virtualiron.com> <45EE8F64.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45EE8F64.76E4.0078.0@novell.com> 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 , Jan Beulich Cc: xen-devel@lists.xensource.com, Ben Thomas List-Id: xen-devel@lists.xenproject.org >>> "Jan Beulich" 07.03.07 10:09 >>> >>>> Keir Fraser 07.03.07 09:27 >>> >>On 6/3/07 22:10, "Ben Thomas" wrote: >> >>> Why are the zones unsigned ints when they are used as indices ? >>> The ASSERTS do checks to keep you out of some amount of >>> trouble, but the loop appears to be able to get you quickly >>> into trouble by driving the index negative and with a check >>> that doesn't appear to be effective. >> >>This is already fixed in the staging tree. > >Hmm, looking at that fix I doubt it helps - since zone_lo and zone_hi remain >unsigned, my understanding would be that the signed zone is converted to >unsigned before the comparison, hence nothing changes. > >And I really think using signed variables for array indices is odd - it performs >worse on x86-64/ia64 at least (because of the extra sign extension, whereas >the zero extension is implied in most/some operations), and it certainly is >contrary to how arrays work (they don't normally have fields accessible with >negative indices). e.g. by instead doing for ( zone = zone_hi + 1; zone-- > zone_lo; ) Jan