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] per_cpu problem

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] per_cpu problem
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Tue, 29 Dec 2009 14:22:48 +0100
Delivery-date: Tue, 29 Dec 2009 05:23:10 -0800
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1262092922; x=1293628922; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Juergen=20Gross=20<juergen.gross@xxxxxxxxxxxxxx> |Subject:=20Re:=20[Xen-devel]=20per_cpu=20problem|Date: =20Tue,=2029=20Dec=202009=2014:22:48=20+0100|Message-ID: =20<4B3A02A8.2030407@xxxxxxxxxxxxxx>|To:=20"xen-devel@lis ts.xensource.com"=20<xen-devel@xxxxxxxxxxxxxxxxxxx> |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<4B39FA03.4010705@xxxxxxxxxxxxxx> |References:=20<4B39FA03.4010705@xxxxxxxxxxxxxx>; bh=BptQPySH358Mq/ZBX3ivYNJRYIN4DKhWw91W7UNjZ08=; b=qUPfyhhc6wjWLkwLhhlUxBD7WzKcTNda8sBlB4TEbUYq0XHAG0SfPifW ePaub9qGBtUaEFQLfEdlnBQMjyn4cC9INLegEthzB8Rlf0+6k1TJ5gboe THQOg5ifcK1quRwz/QImfh1hCGj5rMmfnb05yPr189FCQNmDTgFZV98/s rBFshxc8ACr0bfMTS9dtbkgCGXeTyLSSAueMIpCG8GCWLnjFMzECnHAmb iObXph71jjqzovV+9C0qomAqQJGQp;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:Subject:References:In-Reply-To: X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=XleFr6Jbp3keqIuRjj/6K1J+B0jPHCUFfO7DvIyMPdM3BoY5Nc1UfJc1 7IquRxxkYntroQk9lHsymPALjnLxC/FosERbsOV1YoC3C5xFSxM5g5xJU QokpClZWOI1n+CMFVLG/RB2J8FSnVGmUxHCUdI0FrU6fnWmKovr4ogVKE B3WEqW5rmCt2tfThQvGcvciuWuJ7qCbpp2HOuD1iiMpen4GisZI4q/zWw KPrQrhlV1i5r1y3//t83y1ornLlgH;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B39FA03.4010705@xxxxxxxxxxxxxx>
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>
Organization: Fujitsu Technology Solutions
References: <4B39FA03.4010705@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707)
Juergen Gross wrote:
> Hi,
> 
> I've been playing a little bit with cpu-bound tasklets. For this purpose I
> defined a per_cpu list:
> 
> static DEFINE_PER_CPU(struct list_head, tasklet_list_pcpu);
> 
> The initialization is done in softirq_init:
> 
> void __init softirq_init(void)
> {
>     int i;
> 
>     for_each_possible_cpu ( i )
>     {
>         INIT_LIST_HEAD(&per_cpu(tasklet_list_pcpu, i));
>     }
>     tasklet_pcpu_inited = 1;
>     open_softirq(TASKLET_SOFTIRQ, tasklet_action);
> }
> 
> As soon as a cpu other than cpu 0 is accessing its tasklet_list_pcpu it is
> seeing a non-empty list (I've put a printk in tasklet_action):
> 
> printk("tasklet_list_pcpu(%d) at %p not empty: %p\n", smp_processor_id(),
>        &this_cpu(tasklet_list_pcpu), this_cpu(tasklet_list_pcpu).next);
> 
> Prints out:
> (XEN) tasklet_list_pcpu(1) at ffff82c48026a100 not empty: ffff82c480268100
> 
> Somehow INIT_LIST_HEAD seems to put always the address of the list for cpu 0
> in the list header. Could this be a compiler bug? Is this an artefact of the
> per_cpu macro? Am I missing something?

Okay, I've narrowed things down. I've put a printk in the initialization loop
showing the list address and the contents of list->next:

(XEN) initialized tasklet_list_pcpu(1) at ffff82c48026a100 with ffff82c48026a100

Later the printk in tasklet_action says:

(XEN) tasklet_list_pcpu(1) at ffff82c48026a100 not empty: ffff82c480268100

Who is copying cpu0 data to cpu1???
If this isn't a bug but a feature, I suspect the following in schedule.c is
working only by luck:

void __init scheduler_init(void)
{
    int i;

    open_softirq(SCHEDULE_SOFTIRQ, schedule);

    for_each_possible_cpu ( i )
    {
        spin_lock_init(&per_cpu(schedule_data, i).schedule_lock);
        init_timer(&per_cpu(schedule_data, i).s_timer, s_timer_fn, NULL, i);
    }
...



Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technolgy Solutions               e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

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

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