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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 64BE7C48BCD for ; Wed, 9 Jun 2021 09:59:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 028626128A for ; Wed, 9 Jun 2021 09:59:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 028626128A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 797926B0036; Wed, 9 Jun 2021 05:59:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 72BEE6B006E; Wed, 9 Jun 2021 05:59:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59A9E6B0070; Wed, 9 Jun 2021 05:59:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0229.hostedemail.com [216.40.44.229]) by kanga.kvack.org (Postfix) with ESMTP id 257806B0036 for ; Wed, 9 Jun 2021 05:59:41 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id AF3568249980 for ; Wed, 9 Jun 2021 09:59:40 +0000 (UTC) X-FDA: 78233738520.06.C8F8EBD Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf06.hostedemail.com (Postfix) with ESMTP id 8A697C0091AE for ; Wed, 9 Jun 2021 09:59:36 +0000 (UTC) Received: by mail-lj1-f172.google.com with SMTP id x14so16557879ljp.7 for ; Wed, 09 Jun 2021 02:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=VU9NxlTxI6RSkxw6tvgV5z3t/ysaeFQxXfksToOwW18=; b=XdlwuXVIHAqyX/dYnfnFhPrOEtblNWpTNalxKuzxbtmlQla8K1FKw1xGx0KUCSsjyM LHEcJfxueEq74pMSguJ/gwmu0qKeuwQEH0wt6omaYGb+bhZzGBliVhqqYFmV5WRwRMBW WQ/KGuEMPwerlHG84QzM3QN5rS3ttjTHB/NjPbdGcAaZ/Qxd+/royNrzU3nL1dJPqwB7 T0Zh37PWLQhPQAmKAnMRWvTqJghMSdZjw9Ttq1etJtDNFkfNAT+qGBw1jHRIVDr2y22L tuhTZsFI7K4tz+Kn0LnjeDJXpjckNQgMFUQVOllIXD7EQhh7OAoQjyJLTaEU8rNuIrRQ O+WQ== 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:message-id:references :mime-version:content-disposition:in-reply-to; bh=VU9NxlTxI6RSkxw6tvgV5z3t/ysaeFQxXfksToOwW18=; b=DcJnhON0VaIAgLp4YCDcKqkQOTEA9Vqdol8xkd1TQofP7QpbZA+ZbganF6ooCgy1dA CJQBfra+d8xUQAQdIa1utN7+FwMSJDlpo+xC/JxGf67ZPR+OdNfVxjz4c+yhfX/MfIkC D/jtSWNZcbUTQApIAyM1c5yJ6LLlQV/am75Ya0hqSRvfsTYYpSTU7+w5SGt+qxVYHkJN fp+ZkbbGd2VRPd+ZYt/ANR4lW8KYN0nB9r9BwFhx/3jL39tIF5TMJKP8l28pRSvj6IyI cmaRH9+aqVM1TeJoqwifq1SCqcFSTT4tJn+CIjX1Umqy2mOG9Z7dRaBPzFGzWY/8Dfdx TLkw== X-Gm-Message-State: AOAM530zT9VSH1s2ZjjrRkAkZKk666Mu4nH/pzzsxHlQZKu6p+YmTK0+ e23FJv7ancDcFdDvUyww7Uw7hw== X-Google-Smtp-Source: ABdhPJyZlcIBRL9d2yZNMHgch7D5QXLPUMMCWP1eM7YcWmV2MH+NwuLvc79yy9egtcqUx0T7Ajalgw== X-Received: by 2002:a2e:a16e:: with SMTP id u14mr20973564ljl.343.1623232778569; Wed, 09 Jun 2021 02:59:38 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id a22sm272105ljm.13.2021.06.09.02.59.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Jun 2021 02:59:37 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 136C410265B; Wed, 9 Jun 2021 12:59:53 +0300 (+03) Date: Wed, 9 Jun 2021 12:59:53 +0300 From: "Kirill A. Shutemov" To: Matthew Wilcox 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: <20210609095953.s6bgfjnwkwvjhfo3@box.shutemov.name> 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: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 8A697C0091AE Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=XdlwuXVI; spf=none (imf06.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.208.172) smtp.mailfrom=kirill@shutemov.name; dmarc=none X-Stat-Signature: kbtu9bhpfupy3y71cymwiauut8gh39oc X-HE-Tag: 1623232776-908321 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000021, 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 02:35:23PM +0100, Matthew Wilcox wrote: > 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). Documentation/filesystems/locking.rst: Note, if the filesystem needs the page to be locked during writeout, that is ok, too, the page is allowed to be unlocked at any point in time between the calls to set_page_writeback() and end_page_writeback(). I probably misinterpret what is written here. I know very little about writeback path. > > 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). Maybe we should be smarter on when to wake up, I donno. I just notice that with the change we have /potential/ to wait long time on the wrong page to be unlocked. split_huge_page() interface doesn't enforce that the page gets split soon after split is complete. -- Kirill A. Shutemov