From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1151C10F03 for ; Wed, 24 Apr 2019 02:33:38 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9D078218D3 for ; Wed, 24 Apr 2019 02:33:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D078218D3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=stgolabs.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 44pkrv4n7rzDqRP for ; Wed, 24 Apr 2019 12:33:35 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=softfail (mailfrom) smtp.mailfrom=stgolabs.net (client-ip=195.135.220.15; helo=mx1.suse.de; envelope-from=dave@stgolabs.net; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=stgolabs.net Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 44pkq817P5zDqTV for ; Wed, 24 Apr 2019 12:32:02 +1000 (AEST) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 0466CAF1F; Wed, 24 Apr 2019 02:31:59 +0000 (UTC) Date: Tue, 23 Apr 2019 19:31:52 -0700 From: Davidlohr Bueso To: Daniel Jordan , Christophe Leroy , akpm@linux-foundation.org, Alexey Kardashevskiy , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Paul Mackerras , Christoph Lameter , linuxppc-dev@lists.ozlabs.org, jgg@mellanox.com Subject: Re: [PATCH 5/6] powerpc/mmu: drop mmap_sem now that locked_vm is atomic Message-ID: <20190424023152.vrnyx4r4oapt7vdy@linux-r8p5> Mail-Followup-To: Daniel Jordan , Christophe Leroy , akpm@linux-foundation.org, Alexey Kardashevskiy , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Paul Mackerras , Christoph Lameter , linuxppc-dev@lists.ozlabs.org, jgg@mellanox.com References: <20190402204158.27582-1-daniel.m.jordan@oracle.com> <20190402204158.27582-6-daniel.m.jordan@oracle.com> <964bd5b0-f1e5-7bf0-5c58-18e75c550841@c-s.fr> <20190403164002.hued52o4mga4yprw@ca-dmjordan1.us.oracle.com> <20190424021544.ygqa4hvwbyb6nuxp@linux-r8p5> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20190424021544.ygqa4hvwbyb6nuxp@linux-r8p5> User-Agent: NeoMutt/20180323 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, 23 Apr 2019, Bueso wrote: >On Wed, 03 Apr 2019, Daniel Jordan wrote: > >>On Wed, Apr 03, 2019 at 06:58:45AM +0200, Christophe Leroy wrote: >>>Le 02/04/2019 =E0 22:41, Daniel Jordan a =E9crit=A0: >>>> With locked_vm now an atomic, there is no need to take mmap_sem as >>>> writer. Delete and refactor accordingly. >>> >>>Could you please detail the change ? >> >>Ok, I'll be more specific in the next version, using some of your languag= e in >>fact. :) >> >>>It looks like this is not the only >>>change. I'm wondering what the consequences are. >>> >>>Before we did: >>>- lock >>>- calculate future value >>>- check the future value is acceptable >>>- update value if future value acceptable >>>- return error if future value non acceptable >>>- unlock >>> >>>Now we do: >>>- atomic update with future (possibly too high) value >>>- check the new value is acceptable >>>- atomic update back with older value if new value not acceptable and re= turn >>>error >>> >>>So if a concurrent action wants to increase locked_vm with an acceptable >>>step while another one has temporarily set it too high, it will now fail. >>> >>>I think we should keep the previous approach and do a cmpxchg after >>>validating the new value. > >Wouldn't the cmpxchg alternative also be exposed the locked_vm changing be= tween >validating the new value and the cmpxchg() and we'd bogusly fail even when= there >is still just because the value changed (I'm assuming we don't hold any lo= cks, >otherwise all this is pointless). > > current_locked =3D atomic_read(&mm->locked_vm); > new_locked =3D current_locked + npages; > if (new_locked < lock_limit) > if (cmpxchg(&mm->locked_vm, current_locked, new_locked) =3D=3D curren= t_locked) Err, this being !=3D of course.