Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S274813AbRKKJ75>; Sun, 11 Nov 2001 04:59:57 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S277612AbRKKJ7r>; Sun, 11 Nov 2001 04:59:47 -0500
Received: from colorfullife.com ([216.156.138.34]:11537 "EHLO colorfullife.com")
	by vger.kernel.org with ESMTP id <S274813AbRKKJ7j>;
	Sun, 11 Nov 2001 04:59:39 -0500
Message-ID: <3BEE4C04.4040406@colorfullife.com>
Date: Sun, 11 Nov 2001 10:59:32 +0100
From: Manfred Spraul <manfred@colorfullife.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
X-Accept-Language: en-us
MIME-Version: 1.0
To: Anton Blanchard <anton@samba.org>
CC: "David S. Miller" <davem@redhat.com>, jakub@redhat.com, bcrl@redhat.com,
        torvalds@transmeta.com, alan@lxorguk.ukuu.org.uk, arjanv@redhat.com,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] take 2 of the tr-based current
In-Reply-To: <20011108211143.A4797@redhat.com> <20011109041327.T4087@devserv.devel.redhat.com> <3BEBEE0B.BA1FD7EE@colorfullife.com> <20011109.070312.88700201.davem@redhat.com> <3BEBF730.86CAE1CC@colorfullife.com> <20011111110107.A4064@krispykreme>
Content-Type: multipart/mixed;
 boundary="------------030102060809000108000403"
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

This is a multi-part message in MIME format.
--------------030102060809000108000403
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Anton Blanchard wrote:

>Hi,
>
>>No. const == never changes.
>>get_TR changes if a task calls schedule, and return on another cpu.
>>
>
>Yes, I found this exact problem on ppc64 where we would cache the
>processor data area across a schedule(). What was interesting was that
>__attribute__ ((pure)) was not enough to fix this.
>
>static inline struct Paca *get_paca(void) __attribute__ ((pure));
>static inline struct Paca *get_paca(void)
>{
>	struct Paca *rval;
>	__asm__ ("mfspr %0,0x113" : "=r" (rval));
>	return rval;
>}
>
>Alan Modra came to the rescue and found that gcc was optimising too much
>and since the function did not touch any global variables, it would
>upgrade the pure to const. This was on gcc 3.0.X.
>
But the function called schedule - mustn't gcc assume that schedule 
writes into global variables?
As far as I can see that sounds like a gcc bug.

Could you try how many get_cpu calls are generated by the attached testapp?
the i386 RH compilers generate correct code:
gcc-2.96-98: 4 calls.
gcc3-3.0.1-3: 2 calls.

--
    Manfred

--------------030102060809000108000403
Content-Type: application/msword;
 name="test.c"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="test.c"

I2luY2x1ZGUgPHN0ZGlvLmg+CgpzdGF0aWMgaW50IGNwdSA9IDE7CgpzdGF0aWMgdm9pZCBz
Y2hlZHVsZSh2b2lkKTsKCnN0YXRpYyBpbnQgZ2V0X2NwdSh2b2lkKSBfX2F0dHJpYnV0ZV9f
KChwdXJlKSk7CgppbnQgbWFpbih2b2lkKQp7CglpbnQgY3B1MSwgY3B1MiwgY3B1MywgY3B1
NDsKCWNwdTEgPSBnZXRfY3B1KCk7CgljcHUyID0gZ2V0X2NwdSgpOwoJc2NoZWR1bGUoKTsK
CWNwdTMgPSBnZXRfY3B1KCk7CgljcHU0ID0gZ2V0X2NwdSgpOwoJcHJpbnRmKCJ0aGUgY3B1
IHZhbHVlcyB3ZXJlICVkICVkICVkICVkLlxuIiwKCQljcHUxLCBjcHUyLCBjcHUzLCBjcHU0
KTsKCXJldHVybiAwOwp9CgpzdGF0aWMgaW50IGdldF9jcHUodm9pZCkKewoJcHJpbnRmKCJn
ZXRfY3B1IGNhbGxlZC5cbiIpOwoJcmV0dXJuIGNwdTsKfQoKc3RhdGljIHZvaWQgc2NoZWR1
bGUodm9pZCkKewoJY3B1ID0gMjsKCXByaW50Zigic2NoZWR1bGUgY2FsbGVkIC5cbiIpOwp9
Cg==
--------------030102060809000108000403--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/