Re: [Xen-devel] Xen 4.3 + tmem = Xen BUG at domain_page.c:143

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.06.13 at 17:11, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 12/06/2013 13:12, "Jan Beulich" <JBeulich@xxxxxxxx> 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.

First of all, doubling the entries is not an argument for dropping
that code - the old 32-bit implementation really would have
needed this too from a theoretical perspective: The number of
readily available (garbage) entries is bounded by
MAPCACHE_VCPU_ENTRIES - MAPHASH_ENTRIES (because the
hash entries actively block getting treated as garbage). Adding
MAPHASH_ENTRIES into the calculation of MAPCACHE_VCPU_ENTRIES
would result in header dependency problems (I tried this when I
re-activated that code, as ideally we would want to set this value
to what we anticipate we might need _plus_ MAPHASH_ENTRIES).

Consequently the code should be prepared to recover entries
from the hash anyway (this is particularly relevant when
MAPCACHE_VCPU_ENTRIES <= MAPHASH_ENTRIES - while that's
not the case currently, if someone decided to double the latter
it would be).

Finally, the VA range for this already is an order-17 block (with
the inuse and garbage maps added at the end, i.e. it's slightly
above 512M), so doubling would require the code to be
adjusted to handle a single per-domain block covering two per-
domain slots (each slot covering 1Gb).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel