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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 92DCFC4CEC4 for ; Mon, 23 Sep 2019 17:27:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6DCFE20820 for ; Mon, 23 Sep 2019 17:27:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2407581AbfIWR1E (ORCPT ); Mon, 23 Sep 2019 13:27:04 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59086 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2407411AbfIWR1E (ORCPT ); Mon, 23 Sep 2019 13:27:04 -0400 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x8NHN69O047941; Mon, 23 Sep 2019 13:26:03 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 2v70cvce19-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Sep 2019 13:26:02 -0400 Received: from m0098414.ppops.net (m0098414.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.27/8.16.0.27) with SMTP id x8NHN7wV048081; Mon, 23 Sep 2019 13:26:01 -0400 Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0b-001b2d01.pphosted.com with ESMTP id 2v70cvce0r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Sep 2019 13:26:01 -0400 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id x8NHPD51024308; Mon, 23 Sep 2019 17:26:00 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma04dal.us.ibm.com with ESMTP id 2v5bg72k8b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Sep 2019 17:26:00 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x8NHPxRQ11076200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Sep 2019 17:25:59 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5037BAC05E; Mon, 23 Sep 2019 17:25:59 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 555A3AC059; Mon, 23 Sep 2019 17:25:56 +0000 (GMT) Received: from leobras.br.ibm.com (unknown [9.18.235.184]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 23 Sep 2019 17:25:56 +0000 (GMT) Message-ID: <18c5c378db98f223a0663034baa9fd6ce42f1ec7.camel@linux.ibm.com> Subject: Re: [PATCH v2 11/11] powerpc/mm/book3s64/pgtable: Uses counting method to skip serializing From: Leonardo Bras To: John Hubbard , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Linux-MM Cc: Jason Gunthorpe , Thomas Gleixner , Arnd Bergmann , Greg Kroah-Hartman , YueHaibing , Keith Busch , Nicholas Piggin , Mike Rapoport , Mahesh Salgaonkar , Richard Fontana , Paul Mackerras , "Aneesh Kumar K.V" , Ganesh Goudar , Andrew Morton , Ira Weiny , Dan Williams , Allison Randal Date: Mon, 23 Sep 2019 14:25:51 -0300 In-Reply-To: <4ea26ffb-ad03-bdff-7893-95332b22a5fd@nvidia.com> References: <20190920195047.7703-1-leonardo@linux.ibm.com> <20190920195047.7703-12-leonardo@linux.ibm.com> <1b39eaa7-751d-40bc-d3d7-41aaa15be42a@nvidia.com> <24863d8904c6e05e5dd48cab57db4274675ae654.camel@linux.ibm.com> <4ea26ffb-ad03-bdff-7893-95332b22a5fd@nvidia.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-QkhmEMJu3huKrEpzj07X" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-23_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=661 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909230156 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-QkhmEMJu3huKrEpzj07X Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2019-09-20 at 17:48 -0700, John Hubbard wrote: >=20 [...] > So it seems that full memory barriers (not just compiler barriers) are re= quired. > If the irq enable/disable somehow provides that, then your new code just = goes > along for the ride and Just Works. (You don't have any memory barriers in > start_lockless_pgtbl_walk() / end_lockless_pgtbl_walk(), just the compile= r > barriers provided by the atomic inc/dec.) >=20 > So it's really a pre-existing question about the correctness of the gup_f= ast() > irq disabling approach. I am not experienced in other archs, and I am still pretty new to Power, but by what I could understand, this behavior is better explained in serialize_against_pte_lookup.=20 What happens here is that, before doing a THP split/collapse, the function does a update of the pmd and a serialize_against_pte_lookup, in order do avoid a invalid output on a lockless pagetable walk. Serialize basically runs a do_nothing in every cpu related to the process, and wait for it to return.=20 This running depends on interrupt being enabled, so disabling it before gup_pgd_range() and re-enabling after the end, makes the THP split/collapse wait for gup_pgd_range() completion in every cpu before continuing. (here happens the lock) (As told before, every gup_pgd_range() that occurs after it uses a updated pmd, so no problem.) I am sure other archs may have a similar mechanism using local_irq_{disable,enable}. Did it answer your questions? Best regards, Leonardo Bras --=-QkhmEMJu3huKrEpzj07X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEMdeUgIzgjf6YmUyOlQYWtz9SttQFAl2JAB8ACgkQlQYWtz9S ttRr1Q//T4jMYmkfmx27+Bg69sKonvlgnqSo2pOluY9vzcehO8orfWtP3QQO2WNv ruCYAfCtzUh9x6sByQylolwbt1e/8dI82HBybU4Cy0lgP7ZfDTe+YiWJzMUiUh1l Mm36hPPdVyN3EC0UgWQ7nnfnk2xR7UDOfw701rOzvIsK9P568qP65Iryf7uu0V3n jvZ5JhVJX9eit1OMfEfVBvZigAuv4eAMvu0LK4ko2uTRUgRdkgZa+Pgf9N38Ok8/ iaHvDIcbUaZM/PiHkMSdh1iypyAnkGEYb9zpu0He41DiMOsjSkspvcJPRv19/N7X p71AztGoVXZd02F6tAMkO+794GqIT2/sixX3gUPCCY7d1uhae2d/u5lMhvXK+sCS ktivTMvPqwVfAOGpMheFkugQAu7GhGkUvhslC+YXcZUZJDShK1exMfpbF9slvpEy x8/IkF0EGNWei1jw9iW5ic6b9Abk0WoxwbAAjCgZIkbSliZp9O5eD5+woyMn6DRT c9CSagzNt6ztFsoAMFbtGHq0bgyW8THVNt9Oq1mijpPEwmfGoa7yfMRmt4+KU4bh n6NHbeStFsqhe+59pFTpLRRFkTbMoTQHWsNCLVRlG6fTVZOp0kurs2IjywGqVV8X KyFpkCPlUtX8N69af3sVNbUHG11DDvFF4F+FPPjpRnCpqiyRs3E= =BjCh -----END PGP SIGNATURE----- --=-QkhmEMJu3huKrEpzj07X-- 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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 57CD1C4CECF for ; Mon, 23 Sep 2019 17:28:42 +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 7787C2089F for ; Mon, 23 Sep 2019 17:28:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7787C2089F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 46cWWW02PZzDqLs for ; Tue, 24 Sep 2019 03:28:39 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=linux.ibm.com (client-ip=148.163.158.5; helo=mx0a-001b2d01.pphosted.com; envelope-from=leonardo@linux.ibm.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 46cWT971C1zDqDd for ; Tue, 24 Sep 2019 03:26:36 +1000 (AEST) Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x8NHN69O047941; Mon, 23 Sep 2019 13:26:03 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 2v70cvce19-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Sep 2019 13:26:02 -0400 Received: from m0098414.ppops.net (m0098414.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.27/8.16.0.27) with SMTP id x8NHN7wV048081; Mon, 23 Sep 2019 13:26:01 -0400 Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0b-001b2d01.pphosted.com with ESMTP id 2v70cvce0r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Sep 2019 13:26:01 -0400 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id x8NHPD51024308; Mon, 23 Sep 2019 17:26:00 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma04dal.us.ibm.com with ESMTP id 2v5bg72k8b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Sep 2019 17:26:00 +0000 Received: from b01ledav006.gho.pok.ibm.com (b01ledav006.gho.pok.ibm.com [9.57.199.111]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x8NHPxRQ11076200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 23 Sep 2019 17:25:59 GMT Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5037BAC05E; Mon, 23 Sep 2019 17:25:59 +0000 (GMT) Received: from b01ledav006.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 555A3AC059; Mon, 23 Sep 2019 17:25:56 +0000 (GMT) Received: from leobras.br.ibm.com (unknown [9.18.235.184]) by b01ledav006.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 23 Sep 2019 17:25:56 +0000 (GMT) Message-ID: <18c5c378db98f223a0663034baa9fd6ce42f1ec7.camel@linux.ibm.com> Subject: Re: [PATCH v2 11/11] powerpc/mm/book3s64/pgtable: Uses counting method to skip serializing From: Leonardo Bras To: John Hubbard , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Linux-MM Date: Mon, 23 Sep 2019 14:25:51 -0300 In-Reply-To: <4ea26ffb-ad03-bdff-7893-95332b22a5fd@nvidia.com> References: <20190920195047.7703-1-leonardo@linux.ibm.com> <20190920195047.7703-12-leonardo@linux.ibm.com> <1b39eaa7-751d-40bc-d3d7-41aaa15be42a@nvidia.com> <24863d8904c6e05e5dd48cab57db4274675ae654.camel@linux.ibm.com> <4ea26ffb-ad03-bdff-7893-95332b22a5fd@nvidia.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-QkhmEMJu3huKrEpzj07X" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-23_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=661 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909230156 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: , Cc: Arnd Bergmann , Richard Fontana , Greg Kroah-Hartman , YueHaibing , Nicholas Piggin , Mike Rapoport , Keith Busch , Jason Gunthorpe , Paul Mackerras , "Aneesh Kumar K.V" , Allison Randal , Mahesh Salgaonkar , Ganesh Goudar , Thomas Gleixner , Ira Weiny , Andrew Morton , Dan Williams Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" --=-QkhmEMJu3huKrEpzj07X Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2019-09-20 at 17:48 -0700, John Hubbard wrote: >=20 [...] > So it seems that full memory barriers (not just compiler barriers) are re= quired. > If the irq enable/disable somehow provides that, then your new code just = goes > along for the ride and Just Works. (You don't have any memory barriers in > start_lockless_pgtbl_walk() / end_lockless_pgtbl_walk(), just the compile= r > barriers provided by the atomic inc/dec.) >=20 > So it's really a pre-existing question about the correctness of the gup_f= ast() > irq disabling approach. I am not experienced in other archs, and I am still pretty new to Power, but by what I could understand, this behavior is better explained in serialize_against_pte_lookup.=20 What happens here is that, before doing a THP split/collapse, the function does a update of the pmd and a serialize_against_pte_lookup, in order do avoid a invalid output on a lockless pagetable walk. Serialize basically runs a do_nothing in every cpu related to the process, and wait for it to return.=20 This running depends on interrupt being enabled, so disabling it before gup_pgd_range() and re-enabling after the end, makes the THP split/collapse wait for gup_pgd_range() completion in every cpu before continuing. (here happens the lock) (As told before, every gup_pgd_range() that occurs after it uses a updated pmd, so no problem.) I am sure other archs may have a similar mechanism using local_irq_{disable,enable}. Did it answer your questions? Best regards, Leonardo Bras --=-QkhmEMJu3huKrEpzj07X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEMdeUgIzgjf6YmUyOlQYWtz9SttQFAl2JAB8ACgkQlQYWtz9S ttRr1Q//T4jMYmkfmx27+Bg69sKonvlgnqSo2pOluY9vzcehO8orfWtP3QQO2WNv ruCYAfCtzUh9x6sByQylolwbt1e/8dI82HBybU4Cy0lgP7ZfDTe+YiWJzMUiUh1l Mm36hPPdVyN3EC0UgWQ7nnfnk2xR7UDOfw701rOzvIsK9P568qP65Iryf7uu0V3n jvZ5JhVJX9eit1OMfEfVBvZigAuv4eAMvu0LK4ko2uTRUgRdkgZa+Pgf9N38Ok8/ iaHvDIcbUaZM/PiHkMSdh1iypyAnkGEYb9zpu0He41DiMOsjSkspvcJPRv19/N7X p71AztGoVXZd02F6tAMkO+794GqIT2/sixX3gUPCCY7d1uhae2d/u5lMhvXK+sCS ktivTMvPqwVfAOGpMheFkugQAu7GhGkUvhslC+YXcZUZJDShK1exMfpbF9slvpEy x8/IkF0EGNWei1jw9iW5ic6b9Abk0WoxwbAAjCgZIkbSliZp9O5eD5+woyMn6DRT c9CSagzNt6ztFsoAMFbtGHq0bgyW8THVNt9Oq1mijpPEwmfGoa7yfMRmt4+KU4bh n6NHbeStFsqhe+59pFTpLRRFkTbMoTQHWsNCLVRlG6fTVZOp0kurs2IjywGqVV8X KyFpkCPlUtX8N69af3sVNbUHG11DDvFF4F+FPPjpRnCpqiyRs3E= =BjCh -----END PGP SIGNATURE----- --=-QkhmEMJu3huKrEpzj07X--