WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFO] #2: removing a concurrency bottleneck

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFO] #2: removing a concurrency bottleneck
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 19 Mar 2009 18:27:57 +0000
Cc:
Delivery-date: Thu, 19 Mar 2009 11:28:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <9dff6961-7b13-4447-af9c-f51deef21882@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acmou7bfouO65ckzSCOoxQK+KmRntwABLX5O
Thread-topic: [Xen-devel] [RFO] #2: removing a concurrency bottleneck
User-agent: Microsoft-Entourage/12.15.0.081119
On 19/03/2009 17:52, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> I see two solutions: cascading or per-cpu.
> 
> In per-cpu, I would allocate at system initialization one
> pair of buffers for each cpu (question: num_present_cpus,
> num_online_cpus, or num_possible_cpus?).  Then no lock
> is required.

Just do this. A few pages per cpu is no significant overhead.

I suggest you allocate the buffers and store their addresses in your own
array of size NR_CPUS. You could do this from an __initcall function, or
from some other boot-time init function you have handy. The percpu stuff is
a bit fragile to large allocations (since we manually size the percpu
region!) and you will get no real benefit from it since we do not free/alloc
the percpu regions as cpus are onlined/offlined.

 -- keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>