[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> 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
hash entries actively block getting treated as garbage). Adding
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
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).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.