| 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
| ||
|
Message-ID: <loom.20090311T104939-544@post.gmane.org> Date: Wed, 11 Mar 2009 10:58:41 +0000 (UTC) From: Dmitriy V'jukov <dvyukov@...il.com> To: linux-kernel@...r.kernel.org Subject: RCU: Number of grace-periods In the article "The design of preemptible read-copy-update": http://lwn.net/Articles/253651 Paul McKenney explains why number of grace periods before executing callbacks is set to 2: #define GP_STAGES 2 There are following statements in the reasoning: "Note that because rcu_read_lock() does not contain any memory barriers, the contents of the critical section might be executed early by the CPU" and: "However, because rcu_read_unlock() contains no memory barriers, the contents of the corresponding RCU read-side critical section (possibly including a reference to the item deleted by CPU 0) can be executed late by CPU 1" But on some architectures (IA-32, Intel 64, SPARC TSO) acquire and release fences are implied with every load/store (read - costless), so isn't it possible to reduce the number of required grace periods before executing callbacks on these architectures? I.e. something like: #ifdef ACQUIRE_RELEASE_FENCES_ARE_IMPLIED_ON_ARCH // defined for x86 etc #define GP_STAGES 1 #else #define GP_STAGES 2 #endif Have someone considered such variant? Is it worth doing? Thank you. -- Best regards, Dmitriy V'jukov -- 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