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 1D49EC54EE9 for ; Tue, 27 Sep 2022 20:56:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 806E98E0100; Tue, 27 Sep 2022 16:56:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B6778E00C1; Tue, 27 Sep 2022 16:56:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67D3F8E0100; Tue, 27 Sep 2022 16:56:19 -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 58B0F8E00C1 for ; Tue, 27 Sep 2022 16:56:19 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3450EA0277 for ; Tue, 27 Sep 2022 20:56:19 +0000 (UTC) X-FDA: 79959073278.18.6516F29 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf24.hostedemail.com (Postfix) with ESMTP id BFC40180011 for ; Tue, 27 Sep 2022 20:56:18 +0000 (UTC) Received: by mail-pl1-f174.google.com with SMTP id x1so10148035plv.5 for ; Tue, 27 Sep 2022 13:56:18 -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=JhFaXT/LTm6dJIMFtmVs4nNn7X53gVvoLeA/cKj/Kok=; b=WbxQz3//FCAeiZv7aNflDd8o/IexLIOZYI6UqFZ46vdzRXqmqckoy5VF84QOTdmG6W Amaf6YGuhyuPAUHuzFXEAC1iCjeP9Gy7Hf6ackzi88O/pYboc6aZvxP+/0HYZPnSrGb2 BiAXB8EFN9XDhDYpOPiwwqBdZO8gyja5ReQFjim8JO2Dz/YZK2jkxK0qfQ9M3BDm+dFp cBUzmBuNJxE91ZcD7w5r1d3+11RpJx3m/YT8R9yTahMG9yP1kvDxVaqN8+Je02Ren2Qw xSqh1qggygHKpMUBVOAN29FtO0nSTnyc2scJkPNIBaktSPDMNPW/5HSh+zf3NIVMw3yd Cx9Q== 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=JhFaXT/LTm6dJIMFtmVs4nNn7X53gVvoLeA/cKj/Kok=; b=dBI972YwP/fkVMszSmrUxRzb03oXV77YI3ojsdfbRcyhAZ4wnJ5oArpNFfFogLG1Jh wHXaG52B7+U4MCEjaeuv6trmZ0dHMRLlkKf8q3s41+huHL5sh0zz2sEIr3xrMl8tcZI9 TwPGkhNNVQviKLgaU9J61rCoLyO8GuN7JTM7hD+VE5vxZy4JrBw0wDmNZvDh3Vl6qxgz U8SKzZF0WPJAsmP+EyPBhbNX49TNmegEOezzBeeS7vdAnm8OSRw4yCdUiQ2d5fWROmdT Qvn9qgK7PX29nctyyo2w6hshwbq4ZxRkqM69AR4H+SL06s2jaSpLyMkmKAHaEQ84gSxf +PFw== X-Gm-Message-State: ACrzQf2hq67wSOx7G83ouiei1VSI52yMuBG2JLH8WgSJgjy3aVX5CNdJ RtPB2vhU8klTmbBw7vq6mPZQwCUAMTB0ZajF34s= X-Google-Smtp-Source: AMsMyM7L7/T/vdACPxgn3SYNaVAu/FkJBFcghXQ0Ys4A8wPHzFUnym2G0TWCyawtGwaTnon5uLhyK39Mo4r8Efnr4U8= X-Received: by 2002:a17:903:41c8:b0:177:e7e1:4f4f with SMTP id u8-20020a17090341c800b00177e7e14f4fmr28230270ple.61.1664312177758; Tue, 27 Sep 2022 13:56:17 -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> In-Reply-To: <87ill937qe.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Yang Shi Date: Tue, 27 Sep 2022 13:56:05 -0700 Message-ID: Subject: Re: [RFC 2/6] mm/migrate_pages: split unmap_and_move() to _unmap() and _move() To: "Huang, Ying" Cc: 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=1664312178; a=rsa-sha256; cv=none; b=M0NpnfXOIBptLRZvFhWqNXkCEKdUl/xMhnysFsn4/pjySuYCmh0g3AX1v3QWwBmMul9679 P8rRf9p9g7MfLce7K1lnGf1yKYx0NZHDsjnh2gvs58oWxhqhPyWYHoRNJT+zWslBUH5TMO 49iERRJmmlIVmwg9unN9MrobU54Xw5Y= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="WbxQz3//"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.174 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=1664312178; 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=JhFaXT/LTm6dJIMFtmVs4nNn7X53gVvoLeA/cKj/Kok=; b=Orz3fyYFU7NtHtAEw/0EIw4HYf5Me1CkRSASxxSzHU4s/7PY+Ka+1OMIuBSEVHIF5TVQqO R8YaklDjmzNUkwsXSMX/0AVOMOEG66NeDTS5YmH2DrhE7ODCY0NJD587RafIdQlp6yQHKT O7J3iaLfd8YwiJ8Uz4MTGvpaDXtiqVI= Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="WbxQz3//"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: BFC40180011 X-Stat-Signature: 5ifdxd4de7d4ncpztc1jhodnpc4s6zji X-Rspam-User: X-HE-Tag: 1664312178-179245 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 Mon, Sep 26, 2022 at 6:52 PM Huang, Ying wrote: > > Alistair Popple writes: > > > Yang Shi writes: > > > >> On Mon, Sep 26, 2022 at 2:37 AM Alistair Popple wrote: > >>> > >>> > >>> Huang Ying writes: > >>> > >>> > This is a preparation patch to batch the page unmapping and moving > >>> > for the normal pages and THP. > >>> > > >>> > In this patch, unmap_and_move() is split to migrate_page_unmap() and > >>> > migrate_page_move(). So, we can batch _unmap() and _move() in > >>> > different loops later. To pass some information between unmap and > >>> > move, the original unused newpage->mapping and newpage->private are > >>> > used. > >>> > >>> This looks like it could cause a deadlock between two threads migrating > >>> the same pages if force == true && mode != MIGRATE_ASYNC as > >>> migrate_page_unmap() will call lock_page() while holding the lock on > >>> other pages in the list. Therefore the two threads could deadlock if the > >>> pages are in a different order. > >> > >> It seems unlikely to me since the page has to be isolated from lru > >> before migration. The isolating from lru is atomic, so the two threads > >> unlikely see the same pages on both lists. > > > > Oh thanks! That is a good point and I agree since lru isolation is > > atomic the two threads won't see the same pages. migrate_vma_setup() > > does LRU isolation after locking the page which is why the potential > > exists there. We could potentially switch that around but given > > ZONE_DEVICE pages aren't on an lru it wouldn't help much. > > > >> 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. > > 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. Seems like so... > > Best Regards, > Huang, Ying > > [snip]