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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

close 14
thanks

On Mon, Jul 8, 2013 at 10:07 AM, George Dunlap
<George.Dunlap@xxxxxxxxxxxxx> wrote:
> 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