[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 2/3] Dynamically allocate domain->evtchn, also bump EVTCHNS_PER_BUCKET to 512.
>>> On 03.01.13 at 12:33, Wei Liu <Wei.Liu2@xxxxxxxxxx> wrote: > On Thu, 2013-01-03 at 10:36 +0000, Jan Beulich wrote: >> >>> On 02.01.13 at 15:27, Wei Liu <Wei.Liu2@xxxxxxxxxx> wrote: >> > On Wed, 2013-01-02 at 13:38 +0000, David Vrabel wrote: >> >> On 31/12/12 18:22, Wei Liu wrote: >> >> > From: Wei Liu <liuw@xxxxxxxxx> >> >> >> >> The changeset description needs to say why you're increasing >> >> EVTCHNS_PER_BUCKET. I can't tell why. >> >> >> > >> > Here is the tedious maths. My thought was that it is not very >> > interesting to see this in a change log, so I dropped it. But I will add >> > this in my later re-post of this series... >> > >> > #define EVTCHNS_PER_BUCKET ??? >> > #define NR_EVTCHN_BUCKETS (NR_EVENT_CHANNEL_L3/EVTCHNS_PER_BUCKET) >> > d->evtchn = xzalloc_array(struct evtchn *, NR_EVTCHN_BUCKETS); >> > >> > We need to allow for 3-level evtchn, so use NR_EVENT_CHANNELS_L3 to >> > calculate NR_EVTCHN_BUCKETS. >> > >> > For 64 bit build, NR_EVENT_CHANNELS_L3 is 256k. The original value of >> > EVTCHNS_PER_BUCKET is 128, which means NR_EVTCHN_BUCKETS=2048, thus >> > d->evtchn has size of 2048*8 = 16KB = 4 pages. Given that only Dom0 or >> > driver domain will need 3-level event channel, this is really overkill >> > for most guests. >> > >> > If we bump EVTCHNS_PER_BUCKET to 512, d->evtchn becomes 512 * 8 = 4KB = >> > 1 page, which I think is more space efficient for most guests. >> >> But not suitable for allocation through xmalloc() (as it'll end up >> doing an order-1 page allocation). Either special case it here, or >> BUILD_BUG_ON() the effective size being exactly a page, or we >> may look into finally making xmalloc() return a page with no >> other tracking data when asked for exactly a page's worth of >> bytes. >> > > Is alloc_xen_heap_page suitable? But I presume there is always some > tracking structure somewhere, so I didn't even take that into account > when I did calculation. Yes, alloc_xenheap_page() is the right thing to use for exact page size allocations. There's no tracking structure associated with that (other than struct page_info, which exists regardless of that allocation). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |