From: Rusty Russell <rusty@rustcorp.com.au>
To: davidm@hpl.hp.com
Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com, rth@twiddle.net
Subject: Re: [PATCH] 2.5.1-pre5: per-cpu areas
Date: Thu, 14 Mar 2002 15:37:38 +1100 [thread overview]
Message-ID: <E16lMzi-0002bb-00@wagner.rustcorp.com.au> (raw)
In-Reply-To: Your message of "Wed, 13 Mar 2002 19:55:02 -0800." <15504.7958.677592.908691@napali.hpl.hp.com>
In message <15504.7958.677592.908691@napali.hpl.hp.com> you write:
> OK, I see this. Unfortunately, HIDE_RELOC() causes me problems
> because it prevents me from taking the address of a per-CPU variable.
> This is useful when you have a per-CPU structure (e.g., cpu_info).
> Perhaps there should/could be a version of HIDE_RELOC() that doesn't
> dereference the resulting address?
Yep, valid point. Patch below: please play.
> I am also a bit concerned however about aliasing that the compiler
> might not detect. For example, with this code:
>
> this_cpu(foo) = 13;
> per_cpu(foo, 0) = 15;
> printf("foo=%d\n", this_cpu(foo);
>
> might print the wrong value if gcc thinks that the first and second
> assignment never alias each other. Does HIDE_RELOC() take care of
> this also?
I'd be pretty sure the compiler can't assume that. Richard would
know...
> On a side-note, would you mind moving __per_cpu_data from smp.h into
> compiler.h? I'd like to use it in processor.h and from that file, I
> can't include smp.h due to a recursive dependency.
I had to fight a similar #include battle with sched.h recently.
I came out with the conclusion that it's better to create a new
include than shuffle inappropriate stuff into other includes to solve
these kind of issues.
Cheers!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.7-pre1/include/linux/compiler.h working-2.5.7-pre1-nfarp/include/linux/compiler.h
--- linux-2.5.7-pre1/include/linux/compiler.h Fri Mar 8 14:49:29 2002
+++ working-2.5.7-pre1-nfarp/include/linux/compiler.h Thu Mar 14 15:32:38 2002
@@ -13,10 +13,4 @@
#define likely(x) __builtin_expect((x),1)
#define unlikely(x) __builtin_expect((x),0)
-/* This macro obfuscates arithmetic on a variable address so that gcc
- shouldn't recognize the original var, and make assumptions about it */
-#define RELOC_HIDE(var, off) \
- ({ __typeof__(&(var)) __ptr; \
- __asm__ ("" : "=g"(__ptr) : "0"((void *)&(var) + (off))); \
- *__ptr; })
#endif /* __LINUX_COMPILER_H */
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.7-pre1/include/linux/percpu.h working-2.5.7-pre1-nfarp/include/linux/percpu.h
--- linux-2.5.7-pre1/include/linux/percpu.h Thu Jan 1 10:00:00 1970
+++ working-2.5.7-pre1-nfarp/include/linux/percpu.h Thu Mar 14 15:32:44 2002
@@ -0,0 +1,28 @@
+#ifndef __LINUX_PERCPU_H
+#define __LINUX_PERCPU_H
+
+/* This macro obfuscates arithmetic on a variable address so that gcc
+ shouldn't recognize the original var, and make assumptions about it */
+#define RELOC_HIDE(ptr, off) \
+ ({ __typeof__(ptr) __ptr; \
+ __asm__ ("" : "=g"(__ptr) : "0"((void *)(ptr) + (off))); \
+ __ptr; })
+
+#ifdef CONFIG_SMP
+#define __per_cpu_data __attribute__((section(".data.percpu")))
+
+#ifndef __HAVE_ARCH_PER_CPU
+extern unsigned long __per_cpu_offset[NR_CPUS];
+
+/* var is in discarded region: offset to particular copy we want */
+#define per_cpu(var, cpu) (*RELOC_HIDE(&var, per_cpu_offset(cpu)))
+
+#define this_cpu(var) per_cpu(var, smp_processor_id())
+#endif /* !__HAVE_ARCH_PER_CPU */
+#else
+#define __per_cpu_data
+#define per_cpu(var, cpu) var
+#define this_cpu(var) var
+#endif /* CONFIG_SMP */
+
+#endif /* __LINUX_PERCPU_H */
diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.7-pre1/include/linux/smp.h working-2.5.7-pre1-nfarp/include/linux/smp.h
--- linux-2.5.7-pre1/include/linux/smp.h Mon Mar 11 14:33:14 2002
+++ working-2.5.7-pre1-nfarp/include/linux/smp.h Thu Mar 14 15:32:23 2002
@@ -72,16 +72,6 @@
#define MSG_RESCHEDULE 0x0003 /* Reschedule request from master CPU*/
#define MSG_CALL_FUNCTION 0x0004 /* Call function on all other CPUs */
-#define __per_cpu_data __attribute__((section(".data.percpu")))
-
-#ifndef __HAVE_ARCH_PER_CPU
-extern unsigned long __per_cpu_offset[NR_CPUS];
-
-/* var is in discarded region: offset to particular copy we want */
-#define per_cpu(var, cpu) RELOC_HIDE(var, per_cpu_offset(cpu))
-
-#define this_cpu(var) per_cpu(var, smp_processor_id())
-#endif /* !__HAVE_ARCH_PER_CPU */
#else /* !SMP */
/*
@@ -101,9 +91,5 @@
#define cpu_online_map 1
static inline void smp_send_reschedule(int cpu) { }
static inline void smp_send_reschedule_all(void) { }
-#define __per_cpu_data
-#define per_cpu(var, cpu) var
-#define this_cpu(var) var
-
#endif
#endif
next parent reply other threads:[~2002-03-14 4:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <15504.7958.677592.908691@napali.hpl.hp.com>
2002-03-14 4:37 ` Rusty Russell [this message]
2002-03-14 5:05 ` [PATCH] 2.5.1-pre5: per-cpu areas Jeff Garzik
2002-03-14 11:14 ` Rusty Russell
2002-03-14 11:26 ` Jeff Garzik
2002-03-14 12:16 ` Rusty Russell
2002-03-14 12:25 ` Jeff Garzik
2002-03-15 1:00 ` Richard Henderson
2002-03-14 9:37 ` Richard Henderson
2002-03-14 18:06 ` David Mosberger
[not found] <15504.7958.677592.908691@napali.hpl.hp.com.suse.lists.linux.kernel>
[not found] ` <E16lMzi-0002bb-00@wagner.rustcorp.com.au.suse.lists.linux.kernel>
2002-03-14 8:39 ` Andi Kleen
2002-03-14 11:09 ` Rusty Russell
2002-03-14 11:14 ` Andi Kleen
2002-03-14 19:48 ` H. Peter Anvin
2002-03-14 18:04 ` David Mosberger
2002-03-14 18:51 ` Andi Kleen
2002-03-15 4:07 ` Rusty Russell
2002-03-15 4:19 ` David Mosberger
2002-03-15 5:52 ` Rusty Russell
2002-03-15 9:13 ` Andi Kleen
2002-03-17 7:17 ` Rusty Russell
2002-03-18 7:35 ` Andi Kleen
2002-03-19 0:02 ` Rusty Russell
2002-03-19 0:08 ` J.A. Magallon
2002-03-19 0:15 ` Andi Kleen
2002-03-19 17:05 ` Richard Henderson
2001-12-05 22:09 Rusty Russell
2001-12-06 7:21 ` Keith Owens
2001-12-06 8:07 ` David S. Miller
2001-12-06 9:18 ` Chris Wedgwood
2001-12-07 15:03 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E16lMzi-0002bb-00@wagner.rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=davidm@hpl.hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rth@twiddle.net \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox