From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCHv2 5/5] evtchn: pad struct evtchn to 64 bytes Date: Tue, 16 Jun 2015 10:22:43 +0100 Message-ID: <5580070302000078000855BA@mail.emea.novell.com> References: <1434383299-21833-1-git-send-email-david.vrabel@citrix.com> <1434383299-21833-6-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z4n4x-0007Yz-RQ for xen-devel@lists.xenproject.org; Tue, 16 Jun 2015 09:22:47 +0000 In-Reply-To: <1434383299-21833-6-git-send-email-david.vrabel@citrix.com> Content-Disposition: inline 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: xen-devel@lists.xenproject.org, Keir Fraser , Ian Campbell , Tim Deegan List-Id: xen-devel@lists.xenproject.org >>> On 15.06.15 at 17:48, wrote: > The number of struct evtchn in a page must be a power of two. Under > some workloads performance is improved slightly by padding struct > evtchn to 64 bytes (a cache line), thus putting the per-channel locks > into their own cache line. > > This does not decrease the number of struct evtchn's per-page. > > Signed-off-by: David Vrabel > --- > I'm not sure we actually want to do this. I think it would be better > to pack the struct evtchn and use vmap to turn the pages into a linear > array for quicker lookup. But then you'd end up with two locks on one cache line again. I.e. I can see the possible benefit of making the tree a linear table, but I don't see how that eliminates the desire for the change here. Jan