From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: Scalable Event Channel ABI design (draft A) Date: Tue, 5 Feb 2013 15:54:57 +0000 Message-ID: <51112B51.3050406@citrix.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Keir Fraser Cc: Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 05/02/13 15:49, Keir Fraser wrote: > On 05/02/2013 14:48, "David Vrabel" 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. David