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 B996DC07E9D for ; Tue, 27 Sep 2022 20:58:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C1B38E0101; Tue, 27 Sep 2022 16:58:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 36F448E00C1; Tue, 27 Sep 2022 16:58:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2373E8E0101; Tue, 27 Sep 2022 16:58:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 12BBA8E00C1 for ; Tue, 27 Sep 2022 16:58:03 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8EE8D1A04C2 for ; Tue, 27 Sep 2022 20:58:01 +0000 (UTC) X-FDA: 79959077562.21.096E4C1 Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by imf04.hostedemail.com (Postfix) with ESMTP id 397CA4000B for ; Tue, 27 Sep 2022 20:58:01 +0000 (UTC) Received: by mail-pg1-f181.google.com with SMTP id bh13so10477391pgb.4 for ; Tue, 27 Sep 2022 13:58:00 -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=d8Rj8Gu6AN5MTrodWGK289Ce7G2GZRGaw3FFJPEJszg=; b=Equxq5NSv3SlwTUUxuJJDBwJzdD2LHv/bFSrJTVWX/7CutjYBN6cDYKP8NONysBmaf 3MupduccMRMN4AFZEpls5jk6lcSB0mi/2zG+0VZnQ+S45Ryq0b4V6CjJabB5xnbw6JP/ /QPlKouVl1YsfuPzLpU2M6XmOigDZguU06hzCWM9g6wxnOS+yuneFSk3J8xcZW5UE6aa RtAda/hNf4NirCHE+bPgPexdrfZ+uU+IO0g4O0Ov3t8oTeK986Q22Z1Bm0Eh0oE/Wave nZx66f+kXumFDl3Y1T3F0RN+k7BVtAqvrKXrRaXay7Rvn2R/ztXHOPvn+7BF/e/aF0uD gy3Q== 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=d8Rj8Gu6AN5MTrodWGK289Ce7G2GZRGaw3FFJPEJszg=; b=nsrJQsyGxO9JtbDF2OegkEcEbA1Wgp99xXECjoOa4l51AGJw9+zeJRhJqHaEbrsrYy YuyyY6EvBWtK9sanZLqKOEK3d1cx7UyT9AfZWTXH8w9IG9D5tiwEpT37Pt9GDqL10i+b vxZzyliV4uc40HBNRVuwTsROJiq2DOJenyFEfPpdlNwRDiaR/8+pFKTn84Mq5aPPrS6j 3MpjbFePJLkI/q28jz85N/SzGEt+QYoT8H1pU8IJwQK7pCgNK0T9TPB69RBZ9wXgTAIU BGemyV2f+M+o5QigmiWp5p+ZHK3abJ1lEpZePTSF0DjL+AOHuNdjIvVFE/cEq4CRP4DT t/jA== X-Gm-Message-State: ACrzQf3CxD+1ff73FonttH9E1xnnt8034CsDpqJlaJluggiAsrD9HWbE U9aZlLGVATrRYY2lvdSlRfjD+3KSCrASlqKOAUA= X-Google-Smtp-Source: AMsMyM6rMcK+GhETkHk+EvI7IdkCyqx4SVNsKv46/AY5oHrW6p+Tij74LnlWI/AsI/z/uUMZv2qJhwdHsLYjTf7vxjA= X-Received: by 2002:aa7:88c9:0:b0:541:2b7:d655 with SMTP id k9-20020aa788c9000000b0054102b7d655mr31307229pff.72.1664312280251; Tue, 27 Sep 2022 13:58:00 -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> In-Reply-To: <46807002-c42c-1232-0938-5b48050171ee@nvidia.com> From: Yang Shi Date: Tue, 27 Sep 2022 13:57:47 -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=1664312281; a=rsa-sha256; cv=none; b=1tcSASfIy+xw0fgshOWjOY+Q/GvjIPqsy8D1L1JVT8dMqynRtuzdx9jMpHjBlkELJ+HrY+ x6BVqxOw8KQn5O2M4gAb+NedwaFAns23Lswf8JXNYw5I4Y39lR8kgQH5h2DmiAGVZG3aDW rCm32DnhspWegjLu8aVcb9EUtTy9ulM= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Equxq5NS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.181 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664312281; 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=d8Rj8Gu6AN5MTrodWGK289Ce7G2GZRGaw3FFJPEJszg=; b=ryxdq+CzATQfBTJlcRDS05KGUC6bTWYgYpzgKxtO798befWadCMQhwydNP/ZKtxo8afIyF oGOv1T2HxH9m4JSgf9eKnr2jnsdoywcGN+qMYyLFmBE/P+b0oICeIjYZczTyikXX4d4XwM h5POL3O8jZadnIg+9IqR4KkqDR+jXcE= X-Rspamd-Queue-Id: 397CA4000B X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Equxq5NS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.215.181 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-Stat-Signature: 1ywrrxg7gun68sm17kagtjfubyccx46c X-Rspamd-Server: rspam07 X-HE-Tag: 1664312281-823208 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 1:35 PM John Hubbard wrote: > > On 9/26/22 18:51, Huang, Ying wrote: > >>> But there might be other cases which may incur deadlock, for example, > >>> filesystem writeback IIUC. Some filesystems may lock a bunch of pages > >>> then write them back in a batch. The same pages may be on the > >>> migration list and they are also dirty and seen by writeback. I'm not > >>> sure whether I miss something that could prevent such a deadlock from > >>> happening. > >> > >> I'm not overly familiar with that area but I would assume any filesystem > >> code doing this would already have to deal with deadlock potential. > > > > Thank you very much for pointing this out. I think the deadlock is a > > real issue. Anyway, we shouldn't forbid other places in kernel to lock > > 2 pages at the same time. > > > > 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]. > > The only deadlock prevention convention that I see is the convention of > locking the pages in order of ascending address. That only helps if > everything does it that way, and migrate code definitely does not. > However...I thought that up until now, at least, the migrate code relied > on trylock (which can fail, and so migration can fail, too), to avoid > deadlock. Is that changing somehow, I didn't see it? The trylock is used by async mode which does try to avoid blocking. But sync mode does use lock. The current implementation of migration does migrate one page at a time, so it is not a problem. > > > [1] https://elixir.bootlin.com/linux/latest/source/mm/page-writeback.c#L2296 > > thanks, > > -- > John Hubbard > NVIDIA > > > The simplest solution is to batch page migration only if mode == > > MIGRATE_ASYNC. Then we may consider to fall back to non-batch mode if > > mode != MIGRATE_ASYNC and trylock page fails. > > > >