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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.07.13 at 18:56, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
> 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?

The bug itself got fixed, but the number of hash entries didn't
get increased so far (and as previously indicated I'm not
intending to do so; Keir indicated he might).

Jan


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