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=-14.8 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 8BE19C47080 for ; Tue, 1 Jun 2021 19:10:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 44C7561287 for ; Tue, 1 Jun 2021 19:10:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44C7561287 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 941E36B006C; Tue, 1 Jun 2021 15:10:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9179E6B006E; Tue, 1 Jun 2021 15:10:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7DFEB6B0070; Tue, 1 Jun 2021 15:10:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id 4D00B6B006C for ; Tue, 1 Jun 2021 15:10:52 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E3C91180AD822 for ; Tue, 1 Jun 2021 19:10:51 +0000 (UTC) X-FDA: 78206097102.28.650C9F2 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) by imf22.hostedemail.com (Postfix) with ESMTP id 3D2C4C00CBE8 for ; Tue, 1 Jun 2021 19:10:39 +0000 (UTC) Received: by mail-qk1-f172.google.com with SMTP id q10so15428427qkc.5 for ; Tue, 01 Jun 2021 12:10:51 -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=MFawdZO8qw31LqF1YNPnBQn4vTvNybwM9oOXVgye56w=; b=ZQybl2DUCslmE5zuIPFnC434vrcQxWIlga+QSn3bsxaah8EC05cuOMDYytbpNslCuV wIB03QlJD8Bf7Xzzk7R0JOsDKLdijGQqy9EZDnmgypXfx4DqaEG5HUbIFLRxWdMjW3M3 x4n+qqaRnqiVQXkxGKuI9PX7kpx8rEzaT2RSDXtUGkPU1/9ubWQdOZXmFtW83i1tOgCE LnRZAD31PBCiX9jlnJ7yLn0Nf1Eu0pBxUvt+ZiFjsy/sZK9Vp2RAYwZQd6FOVbIegCxW O3bvFTk54kqrf0mqmC9daGO6HzVpEanjnOWr07bdch+SsFTRsgSCmtgm2HyHRT5rBkfz Qywg== 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=MFawdZO8qw31LqF1YNPnBQn4vTvNybwM9oOXVgye56w=; b=gWDbVHGubKwm9TfxeVjh8uydh9/RJfw7eJMJxgBiPHFxIyG3ycxdSXotuvWeMRbzJe L671XIhoheq8z+uydigUw6ijk+jdzONKTQPmb/jHNGtuoL0sySas+89tKlR4B5JYewec QRAvBEpbZsi9/ewvWwc6HrG0oaIjYO8bKL98IyhTNetQB/Nn4YQVdH/DYuBMffLyDi7w Ory+LGzYm65sYXgYl3eUWOwdogW/VVJHmhlaRyQ4AJnB9USG3k/+R6K0VKNEjkiHF3Z8 Cxlx1lafnlbqlED+4O9SLWwtMqVIu/myxxhNbv03EOCsFIqpknVQty3cc+32Mwfle52z kSVg== X-Gm-Message-State: AOAM530xv1lCP7qRbzqmv5sJaD5xqgyqPK35MvYLgv4HFsFsFTPk3iJN ALI9vocoR+b7RfYx0UHVUUBAlg== X-Google-Smtp-Source: ABdhPJwhCdbmRQb7qVOI9FKquZ+yAv16YOjwlJo0usOfM+ayYHiegotPle8om3w+dPdzgqwHA3ATgA== X-Received: by 2002:a37:7145:: with SMTP id m66mr23082124qkc.379.1622574650524; Tue, 01 Jun 2021 12:10:50 -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 o22sm1101915qtq.89.2021.06.01.12.10.49 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Tue, 01 Jun 2021 12:10:50 -0700 (PDT) Date: Tue, 1 Jun 2021 12:10:48 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Matthew Wilcox cc: Hugh Dickins , Xu Yu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, gavin.dg@linux.alibaba.com, Greg Thelen , Wei Xu , Nicholas Piggin , Vlastimil Babka Subject: Re: [PATCH] mm, thp: relax migration wait when failed to get tail page In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Rspamd-Queue-Id: 3D2C4C00CBE8 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=ZQybl2DU; spf=pass (imf22.hostedemail.com: domain of hughd@google.com designates 209.85.222.172 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-Stat-Signature: 8rhz3d84ozqhjhao7fop5rfgnfsynt4y X-HE-Tag: 1622574639-691319 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000898, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 1 Jun 2021, Matthew Wilcox wrote: > On Tue, Jun 01, 2021 at 09:55:56AM -0700, Hugh Dickins wrote: > > > > Well caught: you're absolutely right that there's a bug there. > > But isn't cond_resched() just papering over the real bug, and > > what it should do is a "page = compound_head(page);" before the > > get_page_unless_zero()? How does that work out in your testing? > > You do realise you're strengthening my case for folios by suggesting > that, don't you? ;-) Hah! Well, I do realize that I'm offering you a marketing opportunity. And you won't believe how many patches I dread to post for fear of that ;-) But I'm not so sure that it strengthens your case: apparently folios had not detected this? Or do you have a hoard of folio-detected fixes waiting for the day, and a folio-kit for each of the stable releases? > > I was going to suggest that it won't make any difference because the > page reference count is frozen, but the freezing happens after the call > to unmap_page(), so it may make a difference. I think that's a good point: I may have just jumped on the missing compound_head(), without thinking it through as far as you have. I'm having trouble remembering the dynamics now; but I think there are cond_resched()s in the unmap_page() part, so the splitter may get preempted even on a non-preempt kernel; whereas the frozen part is all done expeditiously, with interrupts disabled. Greg discovered the same issue recently, but we all got sidetracked, and I don't know where his investigation ended up. He was in favour of cond_resched(), I was in favour of compound_head(); and I think I was coming to the conclusion that if cond_resched() is needed, it should not be there in __migration_entry_wait(), but somewhere up in mm/gup.c, so that other faults that retry, expecting to reschedule on return to userspace, do not get trapped in kernelspace this way. Waiting on migration entries from THP splitting is an egregious example, but others may be suffering too. Hugh