From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Xen 4.3 + tmem = Xen BUG at domain_page.c:143 Date: Wed, 12 Jun 2013 16:27:21 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , George Dunlap , konrad wilk Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 12/06/2013 16:11, "Keir Fraser" wrote: > On 12/06/2013 13:12, "Jan Beulich" wrote: > >>> What we see above is that this failure path succeeds three times, but >>> fails the fourth time: there are, in fact, no zero entries after the >>> garbage clean-up; however, because "inuse" is 32-bit (effectively) and >>> "accum" is 64-bit, ~inuse always has bits 32-63 set, and so will >>> always return true and never fall back to the "something else" >> >> Right, that's what occurred to me too yesterday, but the again >> I knew I had seen this code path executed. Now that I look again, >> I think I understand why: All of my Dom0-s and typical DomU-s >> have a vCPU count divisible by 4, and with MAPCACHE_VCPU_ENTRIES >> being 16, the full unsigned long would always be used. > > Why are we so tight on MAPCACHE_VCPU_ENTRIES? Why not say double that number > and get rid of the accum and the 'replace a hash entry instead' logic > instead? We never used to have it, and it's kind of extra complication and a > bit gross. Could even pull MAPHASH_ENTRIES into config.h and explicitly add it to MAPCACHE_VCPU_ENTRIES. That would be neat would it not? And I believe we have space in the mapcache's perdomain slot to enlarge MAPCACHE_VCPU_ENTRIES in this way (i.e., from 16 to 24). -- Keir > -- Keir > >