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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 362DFC433E1 for ; Mon, 25 May 2020 21:42:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C1FF320776 for ; Mon, 25 May 2020 21:42:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="N787yoS5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C1FF320776 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 361058005D; Mon, 25 May 2020 17:42:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 310DD8E0008; Mon, 25 May 2020 17:42:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FF418005D; Mon, 25 May 2020 17:42:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) by kanga.kvack.org (Postfix) with ESMTP id 09A268E0008 for ; Mon, 25 May 2020 17:42:45 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B9CD6181AC9CB for ; Mon, 25 May 2020 21:42:44 +0000 (UTC) X-FDA: 76856566248.23.news62_8c563b697954e X-HE-Tag: news62_8c563b697954e X-Filterd-Recvd-Size: 3410 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Mon, 25 May 2020 21:42:44 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8DCAC206C3; Mon, 25 May 2020 21:42:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590442963; bh=ToLahLcHS5YuqpF5aWI2D5IGWDxwlGaQIecOqgl9Rgc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=N787yoS5m5UzcN6rHbKjgbFq6/yc6cPmNKh1vvBpEtoQywkkcFgbWdsObtac565F6 IbxprCGv59bVg1JhmZJiv4PS12qwsuO5ndi/qfR7gJJG6mMxARDP6mn4Cfk2mQ0uOb l1PxyIjP+J5vdWOATl3HDUEwcifL/q0W2x1YIhRc= Date: Mon, 25 May 2020 14:42:41 -0700 From: Andrew Morton To: Bibo Mao Cc: Thomas Bogendoerfer , Jiaxun Yang , Huacai Chen , Paul Burton , Dmitry Korotin , Philippe =?ISO-8859-1?Q?Mathieu-Daud=E9?= , Stafford Horne , Steven Price , Anshuman Khandual , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport , Sergei Shtylyov , "Maciej W. Rozycki" , linux-mm@kvack.org, David Hildenbrand Subject: Re: [PATCH v6 1/4] MIPS: Do not flush tlb page when updating PTE entry Message-Id: <20200525144241.f0e55183a846607cdbb0d819@linux-foundation.org> In-Reply-To: <1590375160-6997-1-git-send-email-maobibo@loongson.cn> References: <1590375160-6997-1-git-send-email-maobibo@loongson.cn> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Mon, 25 May 2020 10:52:37 +0800 Bibo Mao wrote: > It is not necessary to flush tlb page on all CPUs if suitable PTE > entry exists already during page fault handling, just updating > TLB is fine. > > Here redefine flush_tlb_fix_spurious_fault as empty on MIPS system. > > ... > > --- a/arch/mips/include/asm/pgtable.h > +++ b/arch/mips/include/asm/pgtable.h > @@ -478,6 +478,8 @@ static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > return __pgprot(prot); > } > > +#define flush_tlb_fix_spurious_fault(vma, address) do { } while (0) > + static inline C would be preferred, if that works. For a number of reasons: - looks nicer - more likely to get a code comment (for some reason) - adds typechecking. So right now a MIPS developer could do struct wibble a; struct wobble b; flush_tlb_fix_spurious_fault(&a, &b); and there would be no compiler warning. Then the code gets merged upstream and in come the embarrassing emails! - avoids unused-var warnings foo() { struct address_space a; struct vm_area_struct v; flush_tlb_fix_spurious_fault(&v, &a); } will generate unused-variable warnings if flush_tlb_fix_spurious_fault() is a macro. Making flush_tlb_fix_spurious_fault() inlined C prevents this.