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 D53C0C07E9D for ; Wed, 28 Sep 2022 01:49:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64FD38E0111; Tue, 27 Sep 2022 21:49:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5FEF88E00C1; Tue, 27 Sep 2022 21:49:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C61C8E0111; Tue, 27 Sep 2022 21:49:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3DC1A8E00C1 for ; Tue, 27 Sep 2022 21:49:41 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 13A47C0936 for ; Wed, 28 Sep 2022 01:49:41 +0000 (UTC) X-FDA: 79959812562.07.2156ABB Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf14.hostedemail.com (Postfix) with ESMTP id AA004100003 for ; Wed, 28 Sep 2022 01:49:40 +0000 (UTC) Received: by mail-pg1-f174.google.com with SMTP id q9so10935736pgq.8 for ; Tue, 27 Sep 2022 18:49:40 -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=1Vfi7AWXnCaO1Cvd6Mq1uY3je2KBMWFZikWbaMnkxjs=; b=IYgVPuHGVgqxXqBtQ4CxDDSitmzKee8iPhjwCnhB5LqwP0ZVxGeasHxlxZAZYeq6lA 31OX8D8oVX7srZsi6Uxggwg9OgePvurQahGvY9h0OjYmh0mqFUYc6omFw38WUNwfPEtV vSYv6BuQ6O/z2mxVNPXO/F++1as6A/Vk+f8cCBX6MF7GbHLqkXZJSzvrC5QK9D/HdpWL jIs0MnvXbDwvlRn0q5ax+iY+h+2HOz5KG/Dc+PONBZftxCHiDUx4zq/0+i2cHyHUok9c SgykyqlCcypggE8IZR/mKQjBhM+mTuZmQpYPJxKOE/oC0npO8xLTKpDsH5vhAoGJzrMM 4wOg== 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=1Vfi7AWXnCaO1Cvd6Mq1uY3je2KBMWFZikWbaMnkxjs=; b=OSTAg3xbEiJ2GDwfszFtjX2ZpXgCrGiBIrNdxiWDhd+N2HXAlOCek+FKK6f/TT1skE LffcFUB8q5mrnDQeRCGeE1VotW3MERcFmGQcGn7YO9LCEcIwSZXr8yhG3OWs3zUKBcz7 4y/snStZaNHa40gnpBB4i4Y6RLySk4kqCHYn2kj3NIZWblkW5iImjDUJexb4KoxaBfaY J6VMFNxu2PT0dUgSqFIRyNk4j6DFtEr+BZ+BBmfMNb3zOOWQ/pZcK0WGqfSN3rqTncj2 YeBrgPiYqtLMOjUI6mZFWIS7LshrXuGooJjBpRhMHnpPrnjUme674RwyYiCB4KlTRHIn FZOw== X-Gm-Message-State: ACrzQf0XosOOmfVJXWlpCL94fT3IMdwHWqEiNUqphSaLeUzjt9A+HcL1 3D5G9GJMapohkRUH44K5JddxVWRIGt6UNBiMkKs= X-Google-Smtp-Source: AMsMyM7RPrYtnz+qDp9SF9zc6a+NCzoGQQItskFz2opRNwqaDk1x3Q1i5kdwn4kq5aetoXezYMNrwvX9bNIBDHpdkYk= X-Received: by 2002:aa7:88c9:0:b0:541:2b7:d655 with SMTP id k9-20020aa788c9000000b0054102b7d655mr32420304pff.72.1664329779633; Tue, 27 Sep 2022 18:49:39 -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> In-Reply-To: <240bbb01-1f26-71ee-233a-ad65313ac358@nvidia.com> From: Yang Shi Date: Tue, 27 Sep 2022 18:49:26 -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=1664329780; a=rsa-sha256; cv=none; b=OCQNXo9mUyuuEpCTXyRgFf7O7PjKHuqxjJlSpCvRHlF2iwRLHPveFsAOJ99a5P8CApFMcn RsZ+44S212x2h/SbKFp5a54GCoBMSBGxqcJxP1ZrTZXhsQ9NHQP498ASr9IJuJsd+fp8bG 0Xs4oqcBAkYgV8XzQYRz6FjAAu6jAJs= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IYgVPuHG; spf=pass (imf14.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.174 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=1664329780; 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=1Vfi7AWXnCaO1Cvd6Mq1uY3je2KBMWFZikWbaMnkxjs=; b=bHHvxnT8/TlAM1XoDuXAF86FVHPYQFxgz3rRuMV2EnO9I8RSqXRJsq3mxWISPaDr44rGGC jCgZQo0RPj+ywNQ4MCnC12ifLOkwFJny8wUNm69h/Z4tsCF0g6eolNo0yMUjicbdLfp+5u fueSnQsI+7Q5GoyIre+HwSzW0tkakLw= X-Rspamd-Server: rspam10 X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IYgVPuHG; spf=pass (imf14.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: rbh349r1ynoosbo8ttwn6ismbbgwnk56 X-Rspamd-Queue-Id: AA004100003 X-HE-Tag: 1664329780-242143 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: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. > > thanks, > > -- > John Hubbard > NVIDIA >