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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 EC9C5C43603 for ; Fri, 13 Dec 2019 21:44:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7CE6324676 for ; Fri, 13 Dec 2019 21:44:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7CE6324676 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 640B08E000F; Fri, 13 Dec 2019 12:50:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F0348E0001; Fri, 13 Dec 2019 12:50:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DF1B8E000F; Fri, 13 Dec 2019 12:50:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) by kanga.kvack.org (Postfix) with ESMTP id 385938E0001 for ; Fri, 13 Dec 2019 12:50:20 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id D41C08249980 for ; Fri, 13 Dec 2019 17:50:19 +0000 (UTC) X-FDA: 76260857358.02.bomb59_3d097e4bc5326 X-HE-Tag: bomb59_3d097e4bc5326 X-Filterd-Recvd-Size: 2985 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Dec 2019 17:50:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id ADF07AC69; Fri, 13 Dec 2019 17:50:17 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 524CF1E0609; Fri, 13 Dec 2019 18:50:17 +0100 (CET) Date: Fri, 13 Dec 2019 18:50:17 +0100 From: Jan Kara To: "lixinhai.lxh@gmail.com" Cc: "Kirill A. Shutemov" , "linux-mm@kvack.org" , jack Subject: Re: [PATCH] mm/memory.c: avoid repeated set_page_dirty in fault_dirty_shared_page Message-ID: <20191213175017.GC15331@quack2.suse.cz> References: <1576164078-28402-1-git-send-email-lixinhai.lxh@gmail.com> <20191212165520.g6rpzvvlyi5wszw6@box> <2019121315283073596252@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <2019121315283073596252@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Content-Transfer-Encoding: quoted-printable 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 13-12-19 15:28:32, lixinhai.lxh@gmail.com wrote: > On 2019-12-13=A0at 00:55=A0Kirill A. Shutemov=A0wrote: > >On Thu, Dec 12, 2019 at 11:21:18PM +0800, Li Xinhai wrote: > >> When vm_ops->page_mkwrite is defined, and called from wp_page_shared= and > >> do_shared_fault, the set_page_dirty must already called by page_mkwr= ite. > > > >Must? Do all ->page_mkwrite implementation do this? >=20 > My understanding is that set_page_dirty need be called before PTE is se= t > to allow writing. If not in this sequence, other thread will see a > writable PTE and dirty the page before current thread=A0set_page_dirty.= =20 Yes, filesystems effectively do rely on this. > In ->page_mkwrite, FS can decide if set_page_dirty=A0should be called o= r > not. I checked a few FS, ext4/xfs/btrsfs/ceph and generic > filemap_page_mkwrite, they called it. If FS=A0provide ->page_mkwrite a= nd > decide don't call set_page_dirty, why fault_dirty_shared_page call this > function unconditionally? or, I missed something? Well, generally the responsibility for dirtying the page has been on the generic MM code (i.e., fault_dirty_shared_page()). Now you're right that lots of filesystems will end up dirtying the page because they are reusin= g generic helpers for handling ->page_mkwrite() and that happens to dirty t= he page. But that is mostly a coincidence and not guarantee. So to safely remove page dirtying from fault_dirty_shared_page(), you'd need to audit *all* ->page_mkwrite() implementations, make sure they all dirty the page= , and then document this requirement somewhere. Overall I don't think the effort is really worth it since redirtying already dirty page is very cheap. Honza --=20 Jan Kara SUSE Labs, CR