From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [RFC] Extending numbers of event channels Date: Mon, 3 Dec 2012 20:56:12 +0000 Message-ID: <20121203205612.GA22913@iceland> References: <1354552154.18784.9.camel@iceland> <50BCF4F9.8010601@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <50BCF4F9.8010601@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.liu2@citrix.com, Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Mon, Dec 03, 2012 at 06:52:41PM +0000, David Vrabel wrote: > On 03/12/12 16:29, Wei Liu wrote: > > Hi all > > > > There has been discussion on extending number of event channels back in > > September [0]. > > It seems that the decision has been made to go for this N-level > approach. Were any other methods considered? > > Would a per-VCPU ring of pending events work? The ABI will be easier to > extend in the future for more event channels. The guest side code will > be simpler. It will be easier to fairly service the events as they will > be processed in the order they were raised. > > The complexity would be in ensuring that events were not lost due to > lack of space in the ring. This may make the ring prohibitively large > or require complex or expensive tracking of pending events inside Xen. > If I understand correctly, one event will always be queued up for processing in the ring model, will this be too overkill? What if event generation is much faster than processing? In the current implementation, one event channel can be raised multiple times but it is only processed once. Wei.