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=-8.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 0194CC56201 for ; Wed, 25 Nov 2020 22:51:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5A0B1206B5 for ; Wed, 25 Nov 2020 22:51:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MQ5Xh/PG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A0B1206B5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7EBBF6B006E; Wed, 25 Nov 2020 17:51:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 777726B0070; Wed, 25 Nov 2020 17:51:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63E806B0071; Wed, 25 Nov 2020 17:51:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 477E56B006E for ; Wed, 25 Nov 2020 17:51:30 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 0E4D2181AEF23 for ; Wed, 25 Nov 2020 22:51:30 +0000 (UTC) X-FDA: 77524438740.01.stone02_3e046282737a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id E85231004CE5D for ; Wed, 25 Nov 2020 22:51:29 +0000 (UTC) X-HE-Tag: stone02_3e046282737a X-Filterd-Recvd-Size: 6363 Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Wed, 25 Nov 2020 22:51:29 +0000 (UTC) Received: by mail-pf1-f196.google.com with SMTP id w6so3758877pfu.1 for ; Wed, 25 Nov 2020 14:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=IdH7TWjWbi5QdZ7NXo5aR6u+Q2zXh+GO9Yj+ORgSPoY=; b=MQ5Xh/PGhwHXhRhZhdNCxder7xSTQ9c8XILgpk60HKNuW8sNh+UTaqxTpHppOOlVWQ LEk5KNshPoI19tYCSjMMkpYh8IxFwqlRSbF7uG4tFoHUCZlILjLHH19JlRqcqVt5U9to r3YgaI2G9fvEGBj5D/6hKThlXZkWyM6HcpyA3AUVHPdvfDzIUdIuwfg5m6VeF8BrXap4 IFiwRQHhgLeiZYuT9Em307w5xlOGeCQMhJarZRfB/PCHv/iE3IPgZov+7Vuo8j8644GA NSKx8d2/AHLcc/Qq6HqYA+TLffx7tlNMv6uaxXZLTLnQW5EzYbUrUHqyi842+5cJ3aRr 0n1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=IdH7TWjWbi5QdZ7NXo5aR6u+Q2zXh+GO9Yj+ORgSPoY=; b=VZWgq/8tCC1PjjmKM4x1CWQ863JHN9P9Pv0c1QNyh0oRfkbQgxkrxEuW+1HSvsAzWE +sxyvuJP51PHDxA74S4QYxFRutmR7n/UhuChOkn4BZdfouC9LYDeUOVleZM9AOUSBYQT qfwU+SxVpBQHnjpKX+zYZ1qsh6jvNbiDfwdunozRVGwMwMAQr5MwrjjFp1qRlhM6u6zM gnMWEn4R5cvxS2U1+QG/f9Gr0YmtH5jXiywlJJLxQm2I563TV7q6ns3ZUSJdPq7JjhA9 Z4WCHzMsc54Vv3UORGXCnN8F0SzpqTe2TdC+zAP8vnp+SKD2EWqwyo6OZN1CVQKErikO ThbQ== X-Gm-Message-State: AOAM533+HmB6Y/R86wRURhi+SmroVGD2lyzEU7+o1XZqSWiBS1HTObjb olx8m5BJi2c7FmgAMNwzPWg= X-Google-Smtp-Source: ABdhPJxsXWrFiRFquDGdwhYbPpoLwY1x6gikdnoflq4amxZ0nT7ZkLwmnkYhG2jA5kMJdJ0EZF4WkQ== X-Received: by 2002:a17:90a:f0cd:: with SMTP id fa13mr14046pjb.118.1606344688500; Wed, 25 Nov 2020 14:51:28 -0800 (PST) Received: from google.com ([2620:15c:211:201:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id v3sm2759284pfn.215.2020.11.25.14.51.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Nov 2020 14:51:27 -0800 (PST) Date: Wed, 25 Nov 2020 14:51:25 -0800 From: Minchan Kim To: Will Deacon Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, kernel-team@android.com, Catalin Marinas , Yu Zhao , Linus Torvalds , Anshuman Khandual , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 4/6] mm: proc: Invalidate TLB after clearing soft-dirty page state Message-ID: <20201125225125.GE1484898@google.com> References: <20201120143557.6715-1-will@kernel.org> <20201120143557.6715-5-will@kernel.org> <20201120150023.GH3040@hirez.programming.kicks-ass.net> <20201120155514.GA3377168@google.com> <20201123184113.GD11688@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201123184113.GD11688@willie-the-truck> 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, Nov 23, 2020 at 06:41:14PM +0000, Will Deacon wrote: > On Fri, Nov 20, 2020 at 07:55:14AM -0800, Minchan Kim wrote: > > On Fri, Nov 20, 2020 at 04:00:23PM +0100, Peter Zijlstra wrote: > > > On Fri, Nov 20, 2020 at 02:35:55PM +0000, Will Deacon wrote: > > > > Since commit 0758cd830494 ("asm-generic/tlb: avoid potential double flush"), > > > > TLB invalidation is elided in tlb_finish_mmu() if no entries were batched > > > > via the tlb_remove_*() functions. Consequently, the page-table modifications > > > > performed by clear_refs_write() in response to a write to > > > > /proc//clear_refs do not perform TLB invalidation. Although this is > > > > fine when simply aging the ptes, in the case of clearing the "soft-dirty" > > > > state we can end up with entries where pte_write() is false, yet a > > > > writable mapping remains in the TLB. > > > > > > > > Fix this by calling tlb_remove_tlb_entry() for each entry being > > > > write-protected when cleating soft-dirty. > > > > > > > > > > > @@ -1053,6 +1054,7 @@ static inline void clear_soft_dirty(struct vm_area_struct *vma, > > > > ptent = pte_wrprotect(old_pte); > > > > ptent = pte_clear_soft_dirty(ptent); > > > > ptep_modify_prot_commit(vma, addr, pte, old_pte, ptent); > > > > + tlb_remove_tlb_entry(tlb, pte, addr); > > > > } else if (is_swap_pte(ptent)) { > > > > ptent = pte_swp_clear_soft_dirty(ptent); > > > > set_pte_at(vma->vm_mm, addr, pte, ptent); > > > > > > Oh! > > > > > > Yesterday when you had me look at this code; I figured the sane thing > > > to do was to make it look more like mprotect(). > > > > > > Why did you chose to make it work with mmu_gather instead? I'll grant > > > you that it's probably the smaller patch, but I still think it's weird > > > to use mmu_gather here. > > > > I agree. The reason why clear_refs_write used the gather API was [1] and > > seems like to overkill to me. > > I don't see why it's overkill. Prior to that commit, it called > flush_tlb_mm() directly. The TLB gather was added for increasing tlb flush pending count for stability bug, not for performance optimiataion(The commit never had any number to support it and didn't have the logic to handle each pte with tlb gather) and then it introduced a bug now so I take it as overkill since it made complication from the beginning *unnecessary*. > > > We could just do like [inc|dec]_tlb_flush_pending with flush_tlb_mm at > > right before dec_tlb_flush_pending instead of gather. > > > > thought? > > I'm not sure why this is better; it's different to the madvise() path, and > will need special logic to avoid the flush in the case where we're just > doing aging. I thought it's better to fix the bug first as *simple* patch and then do optimization based on it. Anyway, following to Yu's comment, we don't need gather API and even the flush if we give up the accuarcy(but I want to have it).