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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 70E94C10F25 for ; Sat, 7 Mar 2020 01:10:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2C8DE206E2 for ; Sat, 7 Mar 2020 01:10:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="EGv7Xx0m" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C8DE206E2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CD74F6B0003; Fri, 6 Mar 2020 20:10:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C5F0C6B0006; Fri, 6 Mar 2020 20:10:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B01F16B0007; Fri, 6 Mar 2020 20:10:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id 93E756B0003 for ; Fri, 6 Mar 2020 20:10:58 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 442908248047 for ; Sat, 7 Mar 2020 01:10:58 +0000 (UTC) X-FDA: 76566786996.18.play22_426a36f2b0228 X-HE-Tag: play22_426a36f2b0228 X-Filterd-Recvd-Size: 6223 Received: from mail-qv1-f67.google.com (mail-qv1-f67.google.com [209.85.219.67]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Sat, 7 Mar 2020 01:10:56 +0000 (UTC) Received: by mail-qv1-f67.google.com with SMTP id e7so1848776qvy.9 for ; Fri, 06 Mar 2020 17:10:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EgkVlU+1chmZAdNkyF5q9aYrIAuysLZZez5WmPdEesQ=; b=EGv7Xx0mZhZufvegZpMUc+XHUkn93SE5ZYbqMRcl5l03s/x6c5RGn1Ma2qadFUAf7S mDQMjSqV0IMWb0LKZbXtHgPTizxmZGQTJdUUxxDOzRNaQofngetBXfwNZBmrbUir4STy e3xaR5vaUH0X/eG5wGlkW6iyRZ9+AVrlHBQUd8rTQK2YW8J6Zd2RLf0s/Z6jQ5Xya9vu aeJUNlgp7kS5lPRKKgCNzhDAIzhO4wqNELMKCmK5Pf7jkprIcuqhfAVWcp5Z+XuxcskU 0FpMxIT78jjgIVAOm8sfqI2jqD5aX8zFE6cx/mP42YiyM5KNoK8iovEJATfquaQSZhHz 6eAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EgkVlU+1chmZAdNkyF5q9aYrIAuysLZZez5WmPdEesQ=; b=sBlTyimLfFeMq0+ZdiBzBTbH9JK3EjzWWtwpowi7g8QviQ9Dzw7Z/bp7U+yfyRM8PD yvRL2Y3uhM5im4uhfllxi/FbdrIrt1fEt79rhVv50muSDH/0/iItFYLNkcfbbrCruj8X Rrp3hrP+YESHfrtWNodA4yI08dDYQIzmuxDJcXJ0uEq7oNENhiUzlWTZvQxcEEx0uTm7 V+TRM9kZ2cn5F0ofvoUIpvQjcz0Lm1NwL045old3scEZYyEwdZvfNDDYoOpG5ROUbt2N ea0YDThi3sO/DLs+qxklOb8F9iYYT91jswxtGogXlq53uSWvU7YW4Vtt49DojAk9BWnC YTyA== X-Gm-Message-State: ANhLgQ34XnI5WKG9gL+XO26GaeT25dRUzPfQPZ6/TOyAUq6RNykC7mdf bDFq+bB2OeQCXRjaM+sJDpWlew== X-Google-Smtp-Source: ADFU+vsw52nux5Uc1WpPZ0fNtyFcwSVbVBgSYAhgVo8M+FINwP2UYIzF3QTk5i6KnfgTnuq5ecGdaA== X-Received: by 2002:a0c:e401:: with SMTP id o1mr5556949qvl.19.1583543455511; Fri, 06 Mar 2020 17:10:55 -0800 (PST) Received: from qians-mbp.fios-router.home (pool-71-184-117-43.bstnma.fios.verizon.net. [71.184.117.43]) by smtp.gmail.com with ESMTPSA id d35sm17605260qtc.21.2020.03.06.17.10.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2020 17:10:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: [PATCH V15] mm/debug: Add tests validating architecture page table helpers From: Qian Cai In-Reply-To: Date: Fri, 6 Mar 2020 20:10:52 -0500 Cc: Linux Memory Management List , Andrew Morton , Mike Rapoport , Vineet Gupta , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "Kirill A . Shutemov" , Paul Walmsley , Palmer Dabbelt , linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, Christophe Leroy Content-Transfer-Encoding: quoted-printable Message-Id: References: <61250cdc-f80b-2e50-5168-2ec67ec6f1e6@arm.com> To: Anshuman Khandual X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Mar 6, 2020, at 7:56 PM, Anshuman Khandual = wrote: >=20 >=20 >=20 > On 03/07/2020 06:04 AM, Qian Cai wrote: >>=20 >>=20 >>> On Mar 6, 2020, at 7:03 PM, Anshuman Khandual = wrote: >>>=20 >>> Hmm, set_pte_at() function is not preferred here for these tests. = The idea >>> is to avoid or atleast minimize TLB/cache flushes triggered from = these sort >>> of 'static' tests. set_pte_at() is platform provided and could/might = trigger >>> these flushes or some other platform specific synchronization stuff. = Just >>=20 >> Why is that important for this debugging option? >=20 > Primarily reason is to avoid TLB/cache flush instructions on the = system > during these tests that only involve transforming different page table > level entries through helpers. Unless really necessary, why should it > emit any TLB/cache flush instructions ? >=20 >>=20 >>> wondering is there specific reason with respect to the soft lock up = problem >>> making it necessary to use set_pte_at() rather than a simple = WRITE_ONCE() ? >>=20 >> Looks at the s390 version of set_pte_at(), it has this comment, >> vmaddr); >>=20 >> /* >> * Certain architectures need to do special things when PTEs >> * within a page table are directly modified. Thus, the following >> * hook is made available. >> */ >>=20 >> I can only guess that powerpc could be the same here. >=20 > This comment is present in multiple platforms while defining = set_pte_at(). > Is not 'barrier()' here alone good enough ? Else what exactly = set_pte_at() No, barrier() is not enough. > does as compared to WRITE_ONCE() that avoids the soft lock up, just = trying > to understand. I surely can spend hours to figure which exact things in set_pte_at() is = necessary for pte_clear() not to stuck, and then propose a solution and possible need = to retest on multiple arches. I am not sure if that is a good use of my time just to = saving a few TLB/cache flush on a debug kernel?=