From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932448AbdKGR7l (ORCPT ); Tue, 7 Nov 2017 12:59:41 -0500 Received: from mail-io0-f169.google.com ([209.85.223.169]:45787 "EHLO mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932350AbdKGR7j (ORCPT ); Tue, 7 Nov 2017 12:59:39 -0500 X-Google-Smtp-Source: ABhQp+SEzpYJWl+3xeYrakSHtOptsaj9egzYJh7hFCi+AFXGElB/8i3+zL+LLKxzkknZuxcZPaS+oQ== From: Andreas Dilger Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D4C818F1-0131-4F25-A12D-80F2E53C082B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH v4] lib/dlock-list: Scale dlock_lists_empty() Date: Tue, 7 Nov 2017 10:59:29 -0700 In-Reply-To: <20171107115921.GC11391@quack2.suse.cz> Cc: Davidlohr Bueso , Waiman Long , Alexander Viro , Jan Kara , Jeff Layton , "J. Bruce Fields" , Tejun Heo , Christoph Lameter , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Andi Kleen , Dave Chinner , Boqun Feng To: Jan Kara References: <1509475860-16139-1-git-send-email-longman@redhat.com> <1509475860-16139-2-git-send-email-longman@redhat.com> <20171102170431.oq3i5mxtjcg53uot@linux-n805> <81bb3365-63f3-fea8-d238-e3880a4c8033@redhat.com> <20171103133420.pngmrsfmtimataz4@linux-n805> <20171103142254.d55bu2n44xe4aruf@linux-n805> <20171106184708.kmwfcchjwjzucuja@linux-n805> <20171107115921.GC11391@quack2.suse.cz> X-Mailer: Apple Mail (2.3273) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --Apple-Mail=_D4C818F1-0131-4F25-A12D-80F2E53C082B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 7, 2017, at 4:59 AM, Jan Kara wrote: > On Mon 06-11-17 10:47:08, Davidlohr Bueso wrote: >> + /* >> + * Serialize dlist->used_lists such that a 0->1 transition is = not >> + * missed by another thread checking if any of the dlock lists = are >> + * used. >> + * >> + * CPU0 CPU1 >> + * dlock_list_add() dlock_lists_empty() >> + * [S] atomic_inc(used_lists); >> + * smp_mb__after_atomic(); >> + * = smp_mb__before_atomic(); >> + * [L] = atomic_read(used_lists) >> + * list_add() >> + */ >> + smp_mb__before_atomic(); >> + return !atomic_read(&dlist->used_lists); Just a general kernel programming question here - I thought the whole = point of atomics is that they are, well, atomic across all CPUs so there is no need for a memory barrier? If there is a need for a memory barrier for each atomic access (assuming it isn't accessed under another lock, which = would make the use of atomic types pointless, IMHO) then I'd think there is a = lot of code in the kernel that isn't doing this properly. What am I missing here? I don't see how this helps if the operations are executed like: * CPU0 CPU1 * dlock_list_add() dlock_lists_empty() * [S] atomic_inc(used_lists); * = smp_mb__before_atomic(); * smp_mb__after_atomic(); * [L] = atomic_read(used_lists) or alternately like: * CPU0 CPU1 * dlock_list_add() dlock_lists_empty() * = smp_mb__before_atomic(); * [S] atomic_inc(used_lists); * smp_mb__after_atomic(); * [L] = atomic_read(used_lists) then the same problem would exist, unless those functions/macros are = somehow bound to the atomic operations themselves? In that case, what makes the = use of atomic_{inc,dec,read}() in other parts of the code safe without them? Cheers, Andreas --Apple-Mail=_D4C818F1-0131-4F25-A12D-80F2E53C082B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFaAfSCpIg59Q01vtYRAmovAKCTPmlV1UUaFFUkQQqqFInRrDLiuwCfftPC 7L0/L9kI3N26yR0lAHZAiso= =lR+i -----END PGP SIGNATURE----- --Apple-Mail=_D4C818F1-0131-4F25-A12D-80F2E53C082B--