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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 65D86C43463 for ; Sun, 20 Sep 2020 03:32:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9245F21775 for ; Sun, 20 Sep 2020 03:32:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ji/gEq92" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9245F21775 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E43526B0003; Sat, 19 Sep 2020 23:32:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF3276B0055; Sat, 19 Sep 2020 23:32:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D08F76B005A; Sat, 19 Sep 2020 23:32:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0043.hostedemail.com [216.40.44.43]) by kanga.kvack.org (Postfix) with ESMTP id B3B196B0003 for ; Sat, 19 Sep 2020 23:32:47 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5E57E8249980 for ; Sun, 20 Sep 2020 03:32:47 +0000 (UTC) X-FDA: 77282017974.18.dime42_4e1556a27139 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin18.hostedemail.com (Postfix) with ESMTP id 3D4B1100ED0FD for ; Sun, 20 Sep 2020 03:32:47 +0000 (UTC) X-HE-Tag: dime42_4e1556a27139 X-Filterd-Recvd-Size: 5131 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Sun, 20 Sep 2020 03:32:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rbEoBPd1LQU1fkvZkwI1VcuWXjyXmuhm2QDCSgPYM3U=; b=ji/gEq92YsPZpGKm8Y06WLZk+N htHK6f+RC1JSFhYfB6/KiqGbskjXyA7CQU4YYRe0UauOS3HvndpTQPBwH4w68RTwBnNpG3Fh++2uu q9wdNQnI0o0L0hVkllG9nLAgklKwpgbqoLl2iWrbYwgvncHJQwIzckpgKpxlge5MMTJJISFcqqLR9 yTjhrGEHzHYkO/SFejU5OYzKe1UiQVllgRstkQvd6CpBFrCdk0gmHdGbmJHzrIuDijpvbMReSDgE/ 9/Kg4XQ2D0+rhQJL08du/AY81H1EKmxdPbr+5IGAtd2qBzMG2VRosj0dtEy/CJ0ey623Wy5DKQYJh in0JKyxw==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kJq5c-0004EC-0Q; Sun, 20 Sep 2020 03:32:36 +0000 Date: Sun, 20 Sep 2020 04:32:35 +0100 From: Matthew Wilcox To: Hugh Dickins Cc: Andrew Morton , alex.shi@linux.alibaba.com, cai@lca.pw, hannes@cmpxchg.org, linux-mm@kvack.org, mhocko@suse.com, mike.kravetz@oracle.com, mm-commits@vger.kernel.org, shakeelb@google.com, shy828301@gmail.com, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: Re: [patch 04/15] shmem: shmem_writepage() split unlikely i915 THP Message-ID: <20200920033235.GR32101@casper.infradead.org> References: <20200918211925.7e97f0ef63d92f5cfe5ccbc5@linux-foundation.org> <20200919042009.bomzxmrg7%akpm@linux-foundation.org> <20200919044408.GL32101@casper.infradead.org> <20200919161847.GN32101@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Sat, Sep 19, 2020 at 05:16:57PM -0700, Hugh Dickins wrote: > On Sat, 19 Sep 2020, Matthew Wilcox wrote: > > How about this for a band-aid until we sort that out properly? Just mark > > the page as dirty before splitting it so subsequent iterations see the > > subpages as dirty. > > This is certainly much better than my original, and I've had no problem > in running with it (briefly); and it's what I'll now keep in my testing > tree - thanks. But it is more obviously a hack, or as you put it, a > band-aid: fit for Linus's tree? > > This issue has only come up with i915 and shmem_enabled "force", nobody > has been bleeding except me: but if it's something that impedes or may > impede your own testing, or that you feel should go in anyway, say so and > I'll push your new improved version to akpm (adding your signoff to mine). No, it's not impeding my testing; I don't have i915 even compiled into my kernel. > > Arguably, we should use set_page_dirty() instead of SetPageDirty, > > My position on that has changed down the years: I went through a > phase of replacing shmem.c's SetPageDirtys by set_page_dirtys, with > the idea that its "if (!PageDirty)" is good to avoid setting cacheline > dirty. Then Spectre changed the balance, so now I'd rather avoid the > indirect function call, and go with your SetPageDirty. But the bdi > flags are such that they do the same thing, and if they ever diverge, > then we make the necessary changes at that time. That makes sense. > > but I don't think i915 cares. In particular, it uses > > an untagged iteration instead of searching for PAGECACHE_TAG_DIRTY. > > PAGECACHE_TAG_DIRTY comes with bdi flags that shmem does not use: > with one exception, every shmem page is always dirty (since its swap > is freed as soon as the page is moved from swap cache to file cache); > unless I'm forgetting something (like the tails in my patch!), the > only exception is a page allocated to a hole on fault (after which > a write fault will soon set pte dirty). Ah, of course. I keep forgetting that shmem doesn't use the dirty/writeback bits. > So I didn't quite get what i915 was doing with its set_page_dirty()s: > but very probably being a good citizen, marking when it exposed the > page to changes itself, making no assumption of what shmem.c does. > > It would be good to have a conversation with i915 guys about huge pages > sometime (they forked off their own mount point in i915_gemfs_init(), > precisely in order to make use of huge pages, but couldn't get them > working, so removed the option to ask for them, but kept the separate > mount point. But not a conversation I'll be responsive on at present.) Yes, I have a strong feeling the i915 shmem code is cargo-culted. There are some very questionable constructs in there. It's a little unfair to expect graphics developers to suddenly become experts on the page cache, so I've taken this as impetus to clean up our APIs a little (eg moving find_lock_entry() to mm/internal.h)