From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 8/8] evtchn: add FIFO-based event channel hypercalls and port ops Date: Wed, 20 Mar 2013 13:42:18 +0000 Message-ID: <5149BCBA.4060106@citrix.com> References: <1363726818-25409-1-git-send-email-david.vrabel@citrix.com> <1363726818-25409-9-git-send-email-david.vrabel@citrix.com> <5149A1E602000078000C71C1@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5149A1E602000078000C71C1@nat28.tlf.novell.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: Jan Beulich Cc: "Keir (Xen.org)" , Konrad Rzeszutek Wilk , Wei Liu , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 20/03/13 10:47, Jan Beulich wrote: >>>> On 19.03.13 at 22:00, David Vrabel wrote: >> +struct evtchn_fifo_queue { >> + volatile uint32_t *head; /* points into control block */ > > I still think that explicit barriers are the way to go. Unless Linux'es > view on this has changed, you'll have issues getting the Linux folks > to accept this. This volatile can just be removed. head is only written by Xen in one place and it is immediately followed by a spin_unlock() which is a barrier. >> @@ -83,6 +83,7 @@ struct evtchn >> u16 virq; /* state == ECS_VIRQ */ >> } u; >> u32 port; >> + struct evtchn_fifo_queue *queue; > > Wouldn't it be better (more space efficient) to store the queue > array index rather than a pointer, considering that you expect to > have thousands of event channels? Yes. David