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 14:48:42 +0000 Message-ID: <51111BCA.3010207@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 04/02/13 19:59, Keir Fraser wrote: > On 04/02/2013 17:52, "David Vrabel" wrote: > >> Hi, >> >> Here is a design for a scalable event channel ABI for Xen. It has a >> number of benefits over the design currently being proposed by Wei Lui. >> >> * More event channels (>100,000). >> * 16 event priorities. >> * Reduced memory requirements (only 1 additional page per domU). >> * The use of FIFOs for events ensures fairness, whereas it is difficult >> to reason about the fairness with the current bitmap system. > > 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. 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. David