linux-kernel - [my_cpu_ptr 0/5] Introduce my_cpu_ptr/__my_cpu

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-next>] [day] [month] [year] [list]

Message-Id: <20090527180635.008102701@gentwo.org>
Date:	Wed, 27 May 2009 13:46:58 -0400
From:	cl@...ux-foundation.org
To:	linux-kernel@...r.kernel.org
Cc:	davem@...emloft.net
Subject: [my_cpu_ptr 0/5] Introduce my_cpu_ptr/__my_cpu_ptr

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 already in some kind of
(arch dependent) efficiently accessible register or memory location.

We can use the per cpu offset instead of doing the array lookup to speed up the
determination of the address of 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. The locations touched by this patchset are potential
candidates for atomic per cpu operations.

The patchset does not cover arch code nor exotic cases where the current
cpu is determined before the call into a function.

-- 
--
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/