Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp100296ybh; Fri, 6 Mar 2020 16:57:32 -0800 (PST) X-Google-Smtp-Source: ADFU+vvMQLMpPD8/VuUIUguEETOPWSpuV4ejWLyoTIFpNDuD+s+GSYvqB7amXgkeZof7d4PY7rzi X-Received: by 2002:a9d:7514:: with SMTP id r20mr4597086otk.265.1583542652348; Fri, 06 Mar 2020 16:57:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583542652; cv=none; d=google.com; s=arc-20160816; b=SZxgi0UmAAkGN7vPqlathDkPNvREEUYTuJkeJ3pnl1mRHINWeUsJTLt6dtu2s8Lf2b XiVGA2uGJ6lGrO+RKJ/ukIhY3FhGHSVjejSYTVSxJEPcobQfv7mNKaUR7zdfyvBwSnwn 9T9I6ji0+E+gFUeBzaBBhP5nigZ/MSannKWNfpYK2wzsSRJ9lwDwYRnAX96s7WbEPDS1 kXa0nxn9pYkMoNQQEWEQbJHH2G5X+MUR6ynHHrSbgFMOPpE/94y0UjW0zpf2xH70tWgY 798l5q1yvopE5y2zY1nRPyyg2O/21oa+JUHA5tdM2+NmXoM5aRV0PfngUHHnzcPtk77u N8wA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Rktz2UHgTnqilT/4mkP+3TeNU4hEvPoe8UlLf+BF/BU=; b=uK+70R6LkHBhIBv5qEvYmdL/RvQ0vSvGBpkCdp18+L2LaAmuK3F1mlUWd7bZu2QJ2Z F5MPxy82CqiYzMjfgl15Qg8jLIRfZNKtBx/jV+vHPB1/N37gKYQVTTV8zgJyKYH8dXxG CXngdAETYdzpDfMML7tj4iZ0C8jCH+eue5AwnWFPPMPQM8LnBu26OuyV/lWuHzQDxRSJ VVY/tIGtSqibACmg6rCz+U1+3Alc2aRmF9Dob550pfiVt77pbQIewiGK9D5pzed2WQS8 lDU5Sw6AP3E43l3SjsKqO07iJfYAcMg4VP3SU3ISk1I+wG/SKxYse8tTga+sUMz736Rc gfgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q3si2380611otc.141.2020.03.06.16.57.20; Fri, 06 Mar 2020 16:57:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726676AbgCGA4u (ORCPT + 99 others); Fri, 6 Mar 2020 19:56:50 -0500 Received: from foss.arm.com ([217.140.110.172]:39878 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726237AbgCGA4u (ORCPT ); Fri, 6 Mar 2020 19:56:50 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7192C30E; Fri, 6 Mar 2020 16:56:49 -0800 (PST) Received: from [10.163.1.59] (unknown [10.163.1.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D25853F237; Fri, 6 Mar 2020 16:56:41 -0800 (PST) Subject: Re: [PATCH V15] mm/debug: Add tests validating architecture page table helpers To: Qian Cai Cc: linux-mm@kvack.org, 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 References: <61250cdc-f80b-2e50-5168-2ec67ec6f1e6@arm.com> From: Anshuman Khandual Message-ID: Date: Sat, 7 Mar 2020 06:26:40 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/07/2020 06:04 AM, Qian Cai wrote: > > >> On Mar 6, 2020, at 7:03 PM, Anshuman Khandual wrote: >> >> 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 > > Why is that important for this debugging option? 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 ? > >> 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() ? > > Looks at the s390 version of set_pte_at(), it has this comment, > vmaddr); > > /* > * Certain architectures need to do special things when PTEs > * within a page table are directly modified. Thus, the following > * hook is made available. > */ > > I can only guess that powerpc could be the same here. 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() does as compared to WRITE_ONCE() that avoids the soft lock up, just trying to understand.