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 6D31EC47082 for ; Tue, 8 Jun 2021 13:35:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F0DA161249 for ; Tue, 8 Jun 2021 13:35:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F0DA161249 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 6DD546B0036; Tue, 8 Jun 2021 09:35:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 68D4D6B006E; Tue, 8 Jun 2021 09:35:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52E026B0070; Tue, 8 Jun 2021 09:35:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id 1E59E6B0036 for ; Tue, 8 Jun 2021 09:35:49 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 93FF198A0 for ; Tue, 8 Jun 2021 13:35:48 +0000 (UTC) X-FDA: 78230654376.32.D8EC52C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id 7B6D5200109D for ; Tue, 8 Jun 2021 13:35:44 +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=riDPbwo++OTuXYeZ0Bw40T80J63Mte6osn02rTiXE80=; b=oTf6wBN4d87+zmVui/ismOVXis 8f2sKfpd48v6VEaJ0yWlEJcuiqjxDpIndI4WRT4NQtxegM1werAAqhchcI8u0gs3g0IiHeB4ypwtp t8xscgHa2qxvXzQX7gDY8Uuy1qQyUaSaytX8Tk2ck/9/4lJXtmOmV8BKzMQuUpw5rwAEkZ1O4k1DS Hffvs4DrlOBR2orC2zlaSOlN1wPdXrjWRsfyuRXlTMDlb6urtuqu5UvKc21xZssTYlEkMkL7M+thQ Kr31qquX/XL6MBLzP6SQFcr46c7TLrswlBcZxv4xCM8AyHzlAuzZ+Hqk9iEetwHpNtZrZh4XVJnOQ iHiAlkJg==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lqbt6-00Gyyh-0i; Tue, 08 Jun 2021 13:35:28 +0000 Date: Tue, 8 Jun 2021 14:35:23 +0100 From: Matthew Wilcox To: "Kirill A. Shutemov" Cc: Xu Yu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, hughd@google.com, akpm@linux-foundation.org, gavin.dg@linux.alibaba.com Subject: Re: [PATCH v2] mm, thp: use head page in __migration_entry_wait Message-ID: References: <20210608120026.ugfh72ydjeba44bo@box.shutemov.name> <20210608125838.6ixdlz3t334gjnp7@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210608125838.6ixdlz3t334gjnp7@box.shutemov.name> Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oTf6wBN4; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Stat-Signature: itac7o8u3ozxneyghg8xkztedfz6rx8y X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7B6D5200109D X-HE-Tag: 1623159344-10146 X-Bogosity: Ham, tests=bogofilter, spamicity=0.013225, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Jun 08, 2021 at 03:58:38PM +0300, Kirill A. Shutemov wrote: > On Tue, Jun 08, 2021 at 01:32:21PM +0100, Matthew Wilcox wrote: > > On Tue, Jun 08, 2021 at 03:00:26PM +0300, Kirill A. Shutemov wrote: > > > But there's one quirk: if split succeed we effectively wait on wrong > > > page to be unlocked. And it may take indefinite time if split_huge_page() > > > was called on the head page. > > > > Hardly indefinite time ... callers of split_huge_page_to_list() usually > > unlock the page soon after. Actually, I can't find one that doesn't call > > unlock_page() within a few lines of calling split_huge_page_to_list(). > > I didn't check all callers, but it's not guaranteed by the interface and > it's not hard to imagine a future situation when a page got split on the > way to IO and kept locked until IO is complete. I would say that can't happen. Pages are locked when added to the page cache and are !Uptodate. You can't put a PTE in a process page table until it's Uptodate, and once it's Uptodate, the page is unlocked. So any subsequent locks are transient, and not for the purposes of IO (writebacks only take the page lock transiently). > The wake up shouldn't have much overhead as in most cases split going to > be called on the head page. I'm not convinced about that. We go out of our way to not wake up pages (eg PageWaiters), and we've had some impressively long lists in the past (which is why we now have the bookmarks).