From: cl@linux-foundation.org
To: linux-kernel@vger.kernel.org
Cc: Tejun Heo <tj@kernel.org>, David Howells <dhowells@redhat.com>,
Ingo Molnar <mingo@elte.hu>,
Rusty Russell <rusty@rustcorp.com.au>,
Eric Dumazet <dada1@cosmosbay.com>
Cc: davem@davemloft.net
Subject: [my_cpu_ptr 1/5] Introduce my_cpu_ptr()
Date: Wed, 27 May 2009 13:46:59 -0400 [thread overview]
Message-ID: <20090527180714.834691580@gentwo.org> (raw)
In-Reply-To: <20090527180635.008102701@gentwo.org>
[-- Attachment #1: my_cpu_ptr_intro --]
[-- Type: text/plain, Size: 2822 bytes --]
my_cpu_ptr(xx) = per_cpu_ptr(xx, smp_processor_id).
The problem with per_cpu_ptr(x, smp_processor_id) is that it requires
an array lookup to find the offset for the cpu. Processors typically
have the offset for the current cpu area in some kind of (arch dependent)
efficiently accessible register or memory location.
We can use that instead of doing the array lookup to speed up the
determination of the addressof the percpu variable. This is particularly
significant because these lookups occur in performance critical paths
of the core kernel.
This optimization is a prerequiste to the introduction of per processor
atomic operations for the core code. Atomic per processor operations
implicitly do the offset calculation to the current per cpu area in a
single instruction. All the locations touched by this patchset are potential
candidates for atomic per cpu operations.
my_cpu_ptr comes in two flavors. The preemption context matters since we
are referring the the currently executing processor. In many cases we must
insure that the processor does not change while a code segment is executed.
__my_cpu_ptr -> Do not check for preemption context
my_cpu_ptr -> Check preemption context
Cc: David Howells <dhowells@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: Christoph Lameter <cl@linux-foundation.org>
---
include/linux/percpu.h | 11 +++++++++++
1 file changed, 11 insertions(+)
Index: linux-2.6/include/linux/percpu.h
===================================================================
--- linux-2.6.orig/include/linux/percpu.h 2009-05-27 11:32:36.000000000 -0500
+++ linux-2.6/include/linux/percpu.h 2009-05-27 11:33:32.000000000 -0500
@@ -78,6 +78,9 @@ extern ssize_t __init pcpu_embed_first_c
*/
#define per_cpu_ptr(ptr, cpu) SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu)))
+#define my_cpu_ptr(ptr) SHIFT_PERCPU_PTR(ptr, my_cpu_offset)
+#define __my_cpu_ptr(ptr) SHIFT_PERCPU_PTR(ptr, __my_cpu_offset)
+
extern void *__alloc_reserved_percpu(size_t size, size_t align);
#else /* CONFIG_HAVE_DYNAMIC_PER_CPU_AREA */
@@ -94,6 +97,12 @@ struct percpu_data {
(__typeof__(ptr))__p->ptrs[(cpu)]; \
})
+#define my_cpu_ptr(ptr) \
+ per_cpu_ptr(ptr, smp_processor_id())
+
+#define __my_cpu_ptr(ptr) \
+ per_cpu_ptr(ptr, raw_smp_processor_id())
+
#endif /* CONFIG_HAVE_DYNAMIC_PER_CPU_AREA */
extern void *__alloc_percpu(size_t size, size_t align);
@@ -102,6 +111,8 @@ extern void free_percpu(void *__pdata);
#else /* CONFIG_SMP */
#define per_cpu_ptr(ptr, cpu) ({ (void)(cpu); (ptr); })
+#define my_cpu_ptr(ptr) per_cpu_ptr(ptr, 0)
+#define __my_cpu_ptr(ptr) my_cpu_ptr(ptr)
static inline void *__alloc_percpu(size_t size, size_t align)
{
--
next prev parent reply other threads:[~2009-05-27 18:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-27 17:46 [my_cpu_ptr 0/5] Introduce my_cpu_ptr/__my_cpu_ptr cl
2009-05-27 17:46 ` cl [this message]
2009-05-28 3:46 ` [my_cpu_ptr 1/5] Introduce my_cpu_ptr() Rusty Russell
2009-05-28 15:59 ` Christoph Lameter
2009-05-29 1:27 ` Rusty Russell
2009-05-29 15:37 ` Christoph Lameter
2009-05-31 3:19 ` Rusty Russell
2009-06-03 14:08 ` Christoph Lameter
2009-05-28 16:10 ` Christoph Hellwig
2009-05-28 16:37 ` Christoph Lameter
2009-05-29 9:46 ` Tejun Heo
2009-05-27 17:47 ` [my_cpu_ptr 2/5] Straight transformations cl
2009-05-27 17:47 ` [my_cpu_ptr 3/5] Elimninate get/put_cpu cl
2009-05-27 19:33 ` Christoph Lameter
2009-05-27 17:47 ` [my_cpu_ptr 4/5] sda_icsb_modify_counters() does not need a "cpu" variable cl
2009-05-28 13:45 ` Olaf Weber
2009-05-27 17:47 ` [my_cpu_ptr 5/5] Use my_cpu_ptr in crypto subsystem cl
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=20090527180714.834691580@gentwo.org \
--to=cl@linux-foundation.org \
--cc=dada1@cosmosbay.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=tj@kernel.org \
/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
all inboxes | Powered by JetHome®