From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 18 Jul 2002 14:55:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 18 Jul 2002 14:55:04 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.101]:18613 "EHLO e1.ny.us.ibm.com") by vger.kernel.org with ESMTP id ; Thu, 18 Jul 2002 14:54:52 -0400 Date: Fri, 19 Jul 2002 00:32:08 +0530 From: Dipankar Sarma To: Linus Torvalds Cc: linux-kernel@vger.kernel.org Subject: [PATCH] read_barrier_depends 2.5.26 Message-ID: <20020719003208.A6466@in.ibm.com> Reply-To: dipankar@in.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus, This patch should also be considered for inclusion along with RCU. This patch adds a read_barrier_depends(), lighter than rmb(), to be used to ensure that data-dependant reads are not re-ordered over this barrier. The patch also adds more descriptive names for the other memory barrier interfaces as you had suggested - http://marc.theaimsgroup.com/?l=linux-kernel&m=100290433130211&w=2 Also included are the list macros useful for use along with RCU (as suggested by Alexey). Thanks -- Dipankar Sarma http://lse.sourceforge.net Linux Technology Center, IBM Software Lab, Bangalore, India. Description : ------------- Sometime ago, during a discussion on lock-free lookups, it was agreed that an additional memory barrier interface, read_barrier_depends() that is lighter than an rmb(), is necessary to make sure that data-dependent reads are not re-ordered over this barrier. For many processors, data-dependency enforces order, so this interface is a NOP, but for those that don't (like alpha), it can be a read_barrier(). For example, the following code would force ordering (the initial value of "a" is zero, "b" is one, and "p" is "&a"): CPU 0 CPU 1 b = 2; memory_barrier(); p = &b; q = p; read_barrier_depends(); d = *q; because the read of "*q" depends on the read of "p" and these two reads should be separated by a read_barrier_depends(). However, the following code, with the same initial values for "a" and "b": CPU 0 CPU 1 a = 2; memory_barrier(); b = 3; y = b; read_barrier_depends(); x = a; does not enforce ordering, since there is no data dependency between the read of "a" and the read of "b". Therefore, on some CPUs, such as Alpha, "y" could be set to 3 and "x" to 0. read_barrier() needs to be used here, not read_barrier_depends(). The original discussion can be found at - http://marc.theaimsgroup.com/?t=100259422200002&r=1&w=2 Explanation of the need for read_barrier_depends() can be found at http://lse.sf.net/locking/wmbdd.html read_barrier_depends-2.5.26-1.patch ----------------------------------- diff -urN linux-2.5.26-base/Documentation/DocBook/kernel-api.tmpl linux-2.5.26-read_barrier_depends/Documentation/DocBook/kernel-api.tmpl --- linux-2.5.26-base/Documentation/DocBook/kernel-api.tmpl Wed Jul 17 05:19:21 2002 +++ linux-2.5.26-read_barrier_depends/Documentation/DocBook/kernel-api.tmpl Wed Jul 17 16:18:17 2002 @@ -41,9 +41,10 @@ !Iinclude/linux/init.h - Atomic and pointer manipulation + Safe memory access and pointer manipulation !Iinclude/asm-i386/atomic.h !Iinclude/asm-i386/unaligned.h +!Iinclude/asm-i386/system.h