lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <463AF095.30406@ac.upc.edu>
Date:	Fri, 04 May 2007 10:36:37 +0200
From:	"Julio M. Merino Vidal" <jmerino@...upc.edu>
To:	Andi Kleen <andi@...stfloor.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Per-CPU data as a structure

Andi Kleen wrote:
>> As far as I can tell, the advantage of percpu is that you can define
>> new "fields" anywhere in the code and independently from the rest of
>> the system. 
>>     
>
> - Independent maintenance as you noted
> - Fast access and relatively compact code
> - Avoids false sharing by keeping cache lines of different CPUs separate
> - Doesn't waste a lot of memory in padding like NR_CPUs arrays usually
> need to to avoid the previous point.
>
> Any replacement that doesn't have these properties too will probably
> be not useful.
>   
Thank you for the details.  I'll try to stick to per-cpu wherever 
possible for now.

Anyway, what do you think about adding the above text to the code (percpu.h
maybe) as documentation?  See the patch below.  (Dunno if the Signed-off-by
line is appropriate as most of the text is yours.)

Signed-off-by: Julio M. Merino Vidal <jmerino@...upc.edu>

diff --git a/include/linux/percpu.h b/include/linux/percpu.h
index 600e3d3..b8e8b8c 100644
--- a/include/linux/percpu.h
+++ b/include/linux/percpu.h
@@ -1,6 +1,21 @@
 #ifndef __LINUX_PERCPU_H
 #define __LINUX_PERCPU_H
 
+/*
+ * percpu provides a mechanism to define variables that are specific to 
each
+ * CPU in the system.
+ *
+ * Each variable is defined as an independent array of NR_CPUS elements.
+ * This approach is used instead of a per-CPU structure because it has the
+ * following advantages:
+ * - Independent maintenance: a source file can define new per-CPU
+ *   variables without distorting others.
+ * - Fast access and relatively compact code.
+ * - Avoids false sharing by keeping cache lines of different CPUs 
separate.
+ * - Doesn't waste a lot of memory in padding like NR_CPUs arrays usually
+ *   need to to avoid the previous point.
+ */
+
 #include <linux/spinlock.h> /* For preempt_disable() */
 #include <linux/slab.h> /* For kmalloc() */
 #include <linux/smp.h>


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ