Re: Xen 4.3 + tmem = Xen BUG at domain_page.c:143

[Keir Fraser <keir.xen@gmail.com>]

On 12/06/2013 13:12, "Jan Beulich" <JBeulich@suse.com> 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.

 -- Keir