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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 A918AC433E0 for ; Fri, 7 Aug 2020 04:35:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7122022CBB for ; Fri, 7 Aug 2020 04:35:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="meBb48lX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7122022CBB 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 D46D86B0002; Fri, 7 Aug 2020 00:35:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF74D6B0003; Fri, 7 Aug 2020 00:35:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0CE26B0005; Fri, 7 Aug 2020 00:35:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A84106B0002 for ; Fri, 7 Aug 2020 00:35:06 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 36AB212CF for ; Fri, 7 Aug 2020 04:35:06 +0000 (UTC) X-FDA: 77122507812.05.boats55_1504a1126fbd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 0DD8A18017AA7 for ; Fri, 7 Aug 2020 04:35:06 +0000 (UTC) X-HE-Tag: boats55_1504a1126fbd X-Filterd-Recvd-Size: 4560 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Fri, 7 Aug 2020 04:35:05 +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 49D0421744; Fri, 7 Aug 2020 04:35:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596774904; bh=5O8qOqoxu6cXV6n8s+ir2UAXTbHifSn0FzcatJDVJZQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=meBb48lXMEMvszs9mFfHQbw+SAFTZepacdQ+fAduyOqNB85rAk9a/6JjN0PkyK9WM +5vk+BkcGUxBrePySKzDt7STTIXfL5zVC/ZFqPxXFHPIzqXM7HfZkUablsN2WfTGXt Tliwrf0i2fUD7DZxJVi+7iMfjjLcOpKKVZyl2zhQ= Date: Thu, 6 Aug 2020 21:35:03 -0700 From: Andrew Morton To: "Aneesh Kumar K.V" Cc: Mike Kravetz , Bibo Mao , Thomas Bogendoerfer , Paul Burton , Anshuman Khandual , Mike Rapoport , Daniel Silsby , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 2/3] mm/huge_memory.c: update tlb entry if pmd is changed Message-Id: <20200806213503.58f40af5f2dd99e386b0f6cb@linux-foundation.org> In-Reply-To: References: <1592990792-1923-1-git-send-email-maobibo@loongson.cn> <1592990792-1923-2-git-send-email-maobibo@loongson.cn> <07f78e99-6e59-0bce-8ac0-50d7c7600461@oracle.com> <87lfkbl5gz.fsf@linux.ibm.com> <6071df89-1438-1a25-136d-228b8863364e@oracle.com> 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-Rspamd-Queue-Id: 0DD8A18017AA7 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Fri, 26 Jun 2020 13:43:06 +0530 "Aneesh Kumar K.V" wrote: > On 6/25/20 10:16 PM, Mike Kravetz wrote: > > On 6/25/20 5:01 AM, Aneesh Kumar K.V wrote: > >> Mike Kravetz writes: > >> > >>> On 6/24/20 2:26 AM, Bibo Mao wrote: > >>>> When set_pmd_at is called in function do_huge_pmd_anonymous_page, > >>>> new tlb entry can be added by software on MIPS platform. > >>>> > >>>> Here add update_mmu_cache_pmd when pmd entry is set, and > >>>> update_mmu_cache_pmd is defined as empty excepts arc/mips platform. > >>>> This patch has no negative effect on other platforms except arc/mips > >>>> system. > >>> > >>> I am confused by this comment. It appears that update_mmu_cache_pmd > >>> is defined as non-empty on arc, mips, powerpc and sparc architectures. > >>> Am I missing something? > >>> > >>> If those architectures do provide update_mmu_cache_pmd, then the previous > >>> patch and this one now call update_mmu_cache_pmd with the actual faulting > >>> address instead of the huge page aligned address. This was intentional > >>> for mips. However, are there any potential issues on the other architectures? > >>> I am no expert in any of those architectures. arc looks like it could be > >>> problematic as update_mmu_cache_pmd calls update_mmu_cache and then > >>> operates on (address & PAGE_MASK). That could now be different. > >>> > >> > >> Also we added update_mmu_cache_pmd to update a THP entry. That could be > >> different from a hugetlb entry on some architectures. If we need to do > >> hugetlb equivalent for update_mmu_cache, we should add a different > >> function. > > > > I do not know the mips architecture well enough or if the motivation for > > this patch was based on THP or hugetlb pages. However, it will change > > the address passed to update_mmu_cache_pmd from huge page aligned to the > > actual faulting address. Will such a change in the passed address impact > > the powerpc update_mmu_cache_pmd routine? > > > > Right now powerpc update_mmu_cache_pmd() is a dummy function. But I > agree we should audit arch to make sure such a change can work with > architectures. My comment was related to the fact that mmu cache update > w.r.t THP and hugetlb can be different on some platforms. So we may > want to avoid using the same function for both. So I'll assume that this patch is stalled until such an audit has taken place?