[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Scalable Event Channel ABI design (draft A)
On Tue, 2013-02-05 at 15:54 +0000, David Vrabel wrote: > On 05/02/13 15:49, Keir Fraser wrote: > > On 05/02/2013 14:48, "David Vrabel" <david.vrabel@xxxxxxxxxx> wrote: > > > >>> I have some sympathy for this design. It's primary downside compared with > >>> the 3-level alternative is its greater space cost (32*#vcpus). However, as > >>> you say the fairness and prioritisation features are rather nice. Also > >>> having the data structures be per vcpu may well help avoid cacheline > >>> contention on busy multi-vcpu guests. > >> > >> This design originally (before I posted it) did have per-VCPU event > >> arrays but I changed it to per-domain to reduce the memory footprint. > > > > Okay, I wonder how much it actually matters anyhow... > > > > Oh by the way you say the control block is 128 bytes and will easily fit in > > the existing struct vcpu_info. That existing structure is 64 bytes in total. > > So how does that work then? > > I meant struct vcpu_info can be extended without it growing to more than > a page. i.e., it fits into the guest page provided in the > VCPUOP_register_vcpu_info call so no additional pages need to be > globally mapped for the control block. VCPUOP_register_vcpu_info doesn't require each vcpu_info to be on a page by itself, even if that happens to be the Linux implementation today (I haven't checked that). Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |