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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9175CC07E9D for ; Wed, 28 Sep 2022 02:14:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E6FB88E0115; Tue, 27 Sep 2022 22:14:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1E1C8E00C1; Tue, 27 Sep 2022 22:14:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC0518E0115; Tue, 27 Sep 2022 22:14:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BE6478E00C1 for ; Tue, 27 Sep 2022 22:14:33 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 930EB1C697D for ; Wed, 28 Sep 2022 02:14:33 +0000 (UTC) X-FDA: 79959875226.10.4FDEEEF Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) by imf09.hostedemail.com (Postfix) with ESMTP id 2D662140004 for ; Wed, 28 Sep 2022 02:14:32 +0000 (UTC) Received: by mail-pg1-f176.google.com with SMTP id r62so7158404pgr.12 for ; Tue, 27 Sep 2022 19:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=2W5JaxbFer3z5OAkUwrQJfU0QqTCG9GKJCIv71u2Re8=; b=ilGkUYPmuYu5Te6RpyJ6i9ewXc4xeF9W1Xs+8uenQaE3WnaZ8oqCVa1PE6iiYXb5HE zIPJQ2xBzHmXJW5BfeTtkipcX2GqnyHWtOjA0KK6ix6xr0aHG7BVcnKPjZ/dYDnyrBdK yYJ3xMERUj00swHg9bB0os5sFnMMLPy+OZYaGZHetwN6w6aCF4c4R5XdgBC1U0/D9eiH PXsvv+Izvuu9aNLzi1OfSAcsvgbEEtWAiwRuPePOPcrX9pOjpfZGzzeclbRdkSeH22dq ZIALr/4FZZM3dTGv3sJIlofeuDabo2Wwk+aPU0B2Bj7iDzve9bEHD8j+k7v4R1SVfrRx HtXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=2W5JaxbFer3z5OAkUwrQJfU0QqTCG9GKJCIv71u2Re8=; b=UtY/MCUjPb1DUiIVfhe+7jTbZEQGnCsCYSSNk67R0MxRqB8llhDvC96AqOeaG4Oj/q UteAAfOHyDYowO0+M8cbLUvwNF4fpkLhvMBVMOV6ehnQ6h8bpw3W6gjyeVR9cXbjFw+o 7sJZ8/4s+wI5TAKVX72PEVvvn1UZcnHmw7vyqXtLfFsuWGxgu7p3grFeI84kXaSjDeuw Z2jHCFfelgGV0GhG77tKujTgOR6ysIhdl8mOtNl7zZhNJplCMg/GjgNuOWYC7O+M+3Hu CG5HjyWBCEoS9QrTVLETmQXfyB0/x5AGJujKUtZer00Y20Y4/2KMeUaKGxxBq1dhzJoq 1JLg== X-Gm-Message-State: ACrzQf2iyBpTLQhU5ow82C4EFuKNrr3FliEvn64yUuIG4+fTFor1xACw +1FK2X0QJV9eE727Yn6QcazOxI7zWxIHUlPscA8= X-Google-Smtp-Source: AMsMyM74PZvJHJzmNokYSrgSFgDkzvXUVfY9Rp1IrLighoEsac0Jdun2PWtxR+g6mhZtACi4WKzjpp/GP1DP0YNP2sI= X-Received: by 2002:aa7:88c9:0:b0:541:2b7:d655 with SMTP id k9-20020aa788c9000000b0054102b7d655mr32508672pff.72.1664331272150; Tue, 27 Sep 2022 19:14:32 -0700 (PDT) MIME-Version: 1.0 References: <20220921060616.73086-1-ying.huang@intel.com> <20220921060616.73086-3-ying.huang@intel.com> <87o7v2lbn4.fsf@nvdebian.thelocal> <87fsgdllmb.fsf@nvdebian.thelocal> <87ill937qe.fsf@yhuang6-desk2.ccr.corp.intel.com> <46807002-c42c-1232-0938-5b48050171ee@nvidia.com> <87pmfgjnpj.fsf@nvdebian.thelocal> <87czbg2s3b.fsf@yhuang6-desk2.ccr.corp.intel.com> <240bbb01-1f26-71ee-233a-ad65313ac358@nvidia.com> <4a44bf59-a984-8ac4-c613-a03d74dc6a5a@nvidia.com> In-Reply-To: <4a44bf59-a984-8ac4-c613-a03d74dc6a5a@nvidia.com> From: Yang Shi Date: Tue, 27 Sep 2022 19:14:19 -0700 Message-ID: Subject: Re: [RFC 2/6] mm/migrate_pages: split unmap_and_move() to _unmap() and _move() To: John Hubbard Cc: "Huang, Ying" , Alistair Popple , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Zi Yan , Baolin Wang , Oscar Salvador , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664331273; a=rsa-sha256; cv=none; b=0N4grSk0bk7RfRnmEgx+M68OC4DTcC2c7D4a14Z/3zm2UUhYZSBAo3Z0RISGAKtz05JxF6 +Id4RMlILd9D+GnrMoWS0VRsBRXOqs3zIsLoJTHe5BGilVlIOrHqfC8mtGKTsfqMTDeYav 69WzO0wMK02s+73GGflXNMEQFtiajl4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ilGkUYPm; spf=pass (imf09.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.176 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664331273; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2W5JaxbFer3z5OAkUwrQJfU0QqTCG9GKJCIv71u2Re8=; b=8KFd4Ea62K3dwrrGHGxobHX/QZtydnupQ/WkrivCwon3uTRcw7UsC7noZcp5qvsLdOvLHp oMJS4b4bew+SRr1hrTa+al+62DYatduZkmTMtNyN/3LaRVc4K3fYQK96JGWw+694r9J2XE w50RE4vrtR7fsk6uvDHm3mcM/oVw7qw= X-Stat-Signature: 1zop3f4598hx37cmm7hcd83rchuf3pm4 X-Rspamd-Queue-Id: 2D662140004 X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ilGkUYPm; spf=pass (imf09.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.176 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam08 X-HE-Tag: 1664331272-30310 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 Tue, Sep 27, 2022 at 6:56 PM John Hubbard wrote: > > On 9/27/22 18:49, Yang Shi wrote: > > On Tue, Sep 27, 2022 at 6:45 PM John Hubbard wrote: > >> > >> On 9/27/22 18:41, Huang, Ying wrote: > >>>>>> I also agree that we cannot make any rules such as "do not lock > 1 page > >>>>>> at the same time, elsewhere in the kernel", because it is already > >>>>>> happening, for example in page-writeback.c, which locks PAGEVEC_SIZE > >>>>>> (15) pages per batch [1]. > >>>> > >>>> That's not really the case though. The inner loop of write_cache_page() > >>>> only ever locks one page at a time, either directly via the > >>>> unlock_page() on L2338 (those goto's are amazing) or indirectly via > >>>> (*writepage)() on L2359. > >>>> > >>>> So there's no deadlock potential there because unlocking any previously > >>>> locked page(s) doesn't depend on obtaining the lock for another page. > >>>> Unless I've missed something? > >>> > >>> Yes. This is my understanding too after checking ext4_writepage(). > >>> > >> > >> Yes, I missed the ".writepage() shall unlock the page" design point. Now > >> it seems much more reasonable and safer. :) > > > > .writepage is deprecated (see > > https://lore.kernel.org/linux-fsdevel/20220719041311.709250-1-hch@lst.de/), > > write back actually uses .writepages. > > write_cache_pages() seems to directly call it, though: > > generic_writepages() > write_cache_pages(__writepage) > __writepage() > mapping->a_ops->writepage(page, wbc) > > So it seems like it's still alive and well. And in any case, it is definitely > passing one page at a time from write_cache_pages(), right? IIRC, the writeback may not call generic_writepages. On my ext4 filesystem, the writeback call stack looks like: @[ ext4_writepages+1 do_writepages+191 __writeback_single_inode+65 writeback_sb_inodes+477 __writeback_inodes_wb+76 wb_writeback+457 wb_workfn+680 process_one_work+485 worker_thread+80 kthread+231 ret_from_fork+34 ]: 2 > > > thanks, > > -- > John Hubbard > NVIDIA >