From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Scalable Event Channel ABI design (draft A) Date: Tue, 05 Feb 2013 15:49:17 +0000 Message-ID: References: <51111BCA.3010207@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51111BCA.3010207@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: David Vrabel Cc: Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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? -- Keir > A hybrid approach might be useful. Busy guests like dom0 or driver > domains could use per-VCPU event arrays but other guests could be > per-domain. This would be controlled by the toolstack. > >> Interested in what others think, but I may actually prefer a ground-up >> redesign like this. > > Since the ABI needs to be changed to support more event channels anyway, > it seems an ideal point to revisit the design.