[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |