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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

close ^
thanks

On Mon, Jul 8, 2013 at 9:58 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> 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

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