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=-12.9 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL 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 CF4AFC43463 for ; Sat, 19 Sep 2020 05:44:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 62CA7207D3 for ; Sat, 19 Sep 2020 05:44:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="cC74EChN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 62CA7207D3 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id C42F88E0001; Sat, 19 Sep 2020 01:44:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF3836B005D; Sat, 19 Sep 2020 01:44:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B090C8E0001; Sat, 19 Sep 2020 01:44:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 9C2FF6B005A for ; Sat, 19 Sep 2020 01:44:50 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4E9602494 for ; Sat, 19 Sep 2020 05:44:50 +0000 (UTC) X-FDA: 77278721940.16.slave06_3a1861827131 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 2B578101217B5 for ; Sat, 19 Sep 2020 05:44:50 +0000 (UTC) X-HE-Tag: slave06_3a1861827131 X-Filterd-Recvd-Size: 5923 Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com [209.85.167.193]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Sat, 19 Sep 2020 05:44:49 +0000 (UTC) Received: by mail-oi1-f193.google.com with SMTP id z26so9827179oih.12 for ; Fri, 18 Sep 2020 22:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=IdgEvO659anbjqoEUxCWG3G4X4Q8jshF4kz+icDVEO0=; b=cC74EChNmXBjUOISk+RHKIrrHyqfgPiP9ZrktBD6i44ja/2RgpItR1qM/yZFM69b2e /ssXccqiKlRJs3IuCDOOvGl5fByQTH3LdNbu9OkssGH7tgts/juYELIFCxVzfI5zUQiU ABwHL2IhU0EQLlMiGfBI8pi6eiwK7I3byPq81X5qTq7ON+Ndx5Cg26s0QI4+SXumiEWB 8ka5vRBsQ7Dk5iJPpTs9z7y4ILa3roiCg1T6N0QaOZOBeuoEKp7PpmQUEr28676tU4h6 mCK1giCUu0AEjP3bfdCZJyPIQuX60Bpj7QOKiNUPc7wkr2xzsMGXSismuYumK5WV2+Z/ ir/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=IdgEvO659anbjqoEUxCWG3G4X4Q8jshF4kz+icDVEO0=; b=jSdAQ9WY6QYe46Zl4ppZt03Rk1fOsHDaBhsGsntYp08w6XVOoFRPP70T42h4kalL9J lXHN2w8yMTdMEWomglgLZSS+iAm4lkdTGgltIOPJFoOLttLfppe0yzYandmXpHqtEkNm /iDzrCYdEguZQGi3W3SoZ2P+L3ophe/n9jHhovtK7g1WAE+kjTxna4gO11mog68HtUbd oFHUp+uib2SSBIIj1UWaLisK/+j2CMlZdEoLaXcSHudFRLgpAaLopFHJUp8AUoUlzLiC AhDrHNJfbu8FpdwfSWzspyabQ2RGdTW5YLoi4HTk6BA5u2J3xSMQ5axuDffmCT8qkqck Hy/A== X-Gm-Message-State: AOAM531YjJ4pv7AvB6HJFtaQqdmFN4muzqQ4J4AmEkeL89tLIgTBY2vc vTs7Lq569li9p5TEqe0FN4I3rQ== X-Google-Smtp-Source: ABdhPJx+43X+/sjynMZCrss0ocZVc3UvE8E4vgymTb3xV51n3atl9j5nsgWTKCFSukJl27Moo3QmrQ== X-Received: by 2002:aca:ad0e:: with SMTP id w14mr98049oie.64.1600494288750; Fri, 18 Sep 2020 22:44:48 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 9sm4455329ois.10.2020.09.18.22.44.46 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Fri, 18 Sep 2020 22:44:47 -0700 (PDT) Date: Fri, 18 Sep 2020 22:44:32 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Matthew Wilcox cc: Andrew Morton , alex.shi@linux.alibaba.com, cai@lca.pw, hannes@cmpxchg.org, hughd@google.com, 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 In-Reply-To: <20200919044408.GL32101@casper.infradead.org> Message-ID: References: <20200918211925.7e97f0ef63d92f5cfe5ccbc5@linux-foundation.org> <20200919042009.bomzxmrg7%akpm@linux-foundation.org> <20200919044408.GL32101@casper.infradead.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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, 19 Sep 2020, Matthew Wilcox wrote: > On Fri, Sep 18, 2020 at 09:20:09PM -0700, Andrew Morton wrote: > > LRU page reclaim always splits the shmem huge page first: I'd prefer not > > to demand that of i915, so check and split compound in shmem_writepage(). > > Sorry for not checking this earlier, but I don't think this is right. > > for (i = 0; i < obj->base.size >> PAGE_SHIFT; i++) { > ... > if (!page_mapped(page) && clear_page_dirty_for_io(page)) { > ... > ret = mapping->a_ops->writepage(page, &wbc); > > so we cleared the dirty bit on the entire hugepage, but then split > it after clearing the dirty bit, so the subpages are now not dirty. > I think we'll lose writes as a result? At least we won't swap pages > out that deserve to be paged out. Very good observation, thank you. It behaves a lot better with this patch in than without it; but you're right, only the head will get written to swap, and the tails left in memory; with dirty cleared, so they may be left indefinitely (I've not yet looked to see when if ever PageDirty might get set later). Hmm. It may just be a matter of restyling the i915 code with if (!page_mapped(page)) { clear_page_dirty_for_io(page); but I don't want to rush to that conclusion - there might turn out to be a good way of doing it at the shmem_writepage() end, but probably only hacks available. I'll mull it over: it deserves some thought about what would suit, if a THP arrived here some other way. We did have some i915 guys Cc'ed on the original posting, but no need to Cc them again until I'm closer to deciding what's right. Linus, Andrew, probably best to drop this patch for now, since no-one else has reported the problem here than me, testing with /sys/kernel/mm/transparent_hugepage/shmem_enabled set to "force"; and what it fixes is not a new regression in 5.9. Though no harm done if the patch goes in: it is an improvement, but seriously incomplete, as Matthew has observed. Hugh > > > > > - VM_BUG_ON_PAGE(PageCompound(page), page); > > + /* > > + * If /sys/kernel/mm/transparent_hugepage/shmem_enabled is "force", > > + * then drivers/gpu/drm/i915/gem/i915_gem_shmem.c gets huge pages, > > + * and its shmem_writeback() needs them to be split when swapping. > > + */ > > + if (PageTransCompound(page)) > > + if (split_huge_page(page) < 0) > > + goto redirty; > > + > > BUG_ON(!PageLocked(page)); > > mapping = page->mapping; > > index = page->index; > > _ > >