[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 Wed, Jun 12, 2013 at 6:26 PM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 12/06/2013 16:48, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>
>>> 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).
>
> So? We have control over both MAPCACHE_VCPU_ENTRUES and MAPHASH_ENTRIES. We
> can make these somewhat arbitrary constants big

So is this bug fixed now?  Can we close it in the bug tracker?

 -George

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


 


Rackspace

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