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 A10EBC77B72 for ; Fri, 14 Apr 2023 19:49:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42A326B007B; Fri, 14 Apr 2023 15:49:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 400F9900003; Fri, 14 Apr 2023 15:49:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F103900002; Fri, 14 Apr 2023 15:49:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1E1B96B007B for ; Fri, 14 Apr 2023 15:49:09 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id ED4211C5EC5 for ; Fri, 14 Apr 2023 19:49:08 +0000 (UTC) X-FDA: 80681035176.04.7DE710E Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf09.hostedemail.com (Postfix) with ESMTP id 3657114000B for ; Fri, 14 Apr 2023 19:49:07 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=tFpwAcRu; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681501747; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ued8RPGYYYnTKpEa2LQkIv8m2xddx8+vhFWcpImfwlQ=; b=zsQ9uN5k7oiwnYTn5VWmYoMOzepHUyI8rbapdtU4lNFINsPwvj9Fp0ZQ+JsFnBGrw/8VMG cyvKROtFafae+Bam9MM284eVDsiBeW9YFH38Z7RwUHQ27tsO3kocpQA5sRxBeX1muHgZEY 3J8DnV3NeIlK3TZpOSSqtMm8wyZ1D9o= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=tFpwAcRu; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681501747; a=rsa-sha256; cv=none; b=G9lWY9L6Np+ac6W7HgKOZg8lQVV3kfyEcJJ31PkyAyaGuunzzrLdVDHVzUvpeT1ivcwDqa 5hiT/leNNx/Dlg72YqK7PfPsgbcnr3qF6HA14p1cs60o5JNRw4oo8ZfADIjlxDjV6klhvY qJuvv10jVB7RohhM7I+RHkRQkgN9ygI= Received: by mail-yb1-f177.google.com with SMTP id o11so1087986ybk.11 for ; Fri, 14 Apr 2023 12:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681501746; x=1684093746; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ued8RPGYYYnTKpEa2LQkIv8m2xddx8+vhFWcpImfwlQ=; b=tFpwAcRuO/oWarfIbQRGNUHywoAJAdE9Xr73K/XoYX/+lNNn90EfAngAnAUgZsn6K6 qqlnwgtqd4LExnuakpYn63uO+fhrxTuyWr64ifHof0eLfAnMocwgHB8vuefYoby+u8fg BdeArXXzre+hm9KxIuaqyLhxfYpgUfp0h69B16oTP3FM5+oE/i9CmSfv6S2NK1u7L+EG OTBmnQDRZLFAUumpp2AV1kYLnHuEKLls9qwqjESqhSvYrUrQiTMrhyTTeaDlrm5j8wL0 41rEK1DT0Ue4LSFHEvGsQQXGWnSdzqYM283OSgJMi10XGPXIrBPMSkI56q/Y8y+Pbf5U 11QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681501746; x=1684093746; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ued8RPGYYYnTKpEa2LQkIv8m2xddx8+vhFWcpImfwlQ=; b=U+xPVftXUc4xuEJ6OFSPX9Dh+9eZa4uGhx1oYuzfuid1aqo68VlZH806msjgys6Akb Q7NVbFdHKxKEg0Xkz3qe14cSVnhrs4iNu4DuIHQkvaQw6v+OoHx3goB53j+iYUtujeeG au9rd2v6WlB8k9QwHU9TrE1mvjYE/WY4fVvnyv+JBdmYiFNJkfYeLbYk/pgnch2ATGsh W0NcODqTTmUlhlHw07KZWavF5vA0kbT8g+TVaM5sMa/z7/8FLE6mYStvkiIHxNNdyv6k +WcJirMo3aai9TtWCGBagJNrWChp8yE+sQeWTDDdswRkC7+i/Vo+0vypICbEzbIzLHUL mrxw== X-Gm-Message-State: AAQBX9couaFh/DIAzvoDz3wjSyZX7MpL1kzxalFIwxvGcNQaTM/vfcWY FBY3612aQheeNRCc/iJdt4nwEJtMwdGj6Q8HLPbE3g== X-Google-Smtp-Source: AKy350bcXIOSLr/r2359jbDN5GOP5UXH4qto8PUFwqeUA+xt82gxkvE3IT8IM15dZAvOWwSCO2EtaPkwUH3+8tAqCWI= X-Received: by 2002:a25:d057:0:b0:b8f:5c64:cc2e with SMTP id h84-20020a25d057000000b00b8f5c64cc2emr3418935ybg.12.1681501746075; Fri, 14 Apr 2023 12:49:06 -0700 (PDT) MIME-Version: 1.0 References: <20230414180043.1839745-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 14 Apr 2023 12:48:54 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: handle swap page faults if the faulting page can be locked To: Matthew Wilcox Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, mhocko@suse.com, josef@toxicpanda.com, jack@suse.cz, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, michel@lespinasse.org, liam.howlett@oracle.com, jglisse@google.com, vbabka@suse.cz, minchan@google.com, dave@stgolabs.net, punit.agrawal@bytedance.com, lstoakes@gmail.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 3657114000B X-Stat-Signature: k5cmusb1nzt4tfdo6594xhnguicyf98c X-HE-Tag: 1681501747-593961 X-HE-Meta: U2FsdGVkX18SHTswcvhN0HdZwf6dA2QApV29B8HWzCXAffmi2R4+8+l3vk29L63OqtupQgeseuPOPihnYtCHo0m6WEgaGsjesgIFRPnDHdQrD4X7BK6dg1Xi+NsPX2dBQurXI04WxbHlurNyEvWIUZHFVfbhLzMktX7bRL4cZv0/NUzc7PMCcofULuQ5guBpARmSG88wjvzoH7eMvR+9/rA8ZxxrOAlWjxHvrhlFogtr8wck0YwrPwaE68NRcQfyEz5z8ZUXwrHuQ9e7uo4qtnu5jMej/mUe8OfMWxTq3RnOq/5OwvcHrcJtWzQ0MKDMxiu6EwDBG9904q3ivOn4c41QeyHbgT1ooj2xaBFydgQDlp2CC9f78zdlnYWzDAXWnEer4HcD07pC7+XfcOHk2YsiUKDSBDb/N48wdQxG6upJrUu5+0CJcEMH94+4+UBlCKO82604fVcNQLiROxkx/iP3Gpch8nJGUUQ1qvKvMrALNVw7bIu7NgYhTlFiUWgVS9B7ij9BPDlMO8ctZPnNwN+GLW8AN5K4PzFtirIK6XgZlsscNfqlThbkp9KOjg/c65Vh2ViaeZfzwrUmIwE8xK6dq0l8jkodMB8gCQWkISgRXoBEAySPq+yl8aRkzNYK+TWg+SV5yug3H3rmiMBJm7XCfFssVTsnp99mFx0iP9L3MwhaHyP0uMRP5VVVH64ynhG8RlmR8mA3YwFkx6oZDNqEDW+67GTCfTiNv7i90+SX6yMVJLo0TIxo87fcKmhwQxDigw15V25rD9JcuGypruUw20eLSwvlrMQGqe0mOhP0a628scE8rGOyh9yJEehf7fAXgujsqLyxOtRIG5NnMaMib3s2WgxQKDKRrnbB5rtBPx6IPhyLAGrob6wIUt8U5e5khiiYNhrp5oWRH1qowlZivSmiqzuI6i23ZJe+xyaCd5ZcC3AEuD1T5NXajilz0RloxuxQ70K5FgXaOgg 6HzccGNt NXXLBKRsmiDSObCxVViFJkT/ZILIIZH+Lkj/ob8D49mT/bdYKrVNYKaQejCZuQ1/di0Dde8PoB9mTxQzat9h+XubnypxJPff1x0/Q8QkkEFjS3ifRS/57563vkP0X6py1532N0USBiatt/SapHVCw2Qe/mT1DKbTQkSiZH2BvwgMw2B3HVuVtS7UTBpEvYtXgiMBU1rrqhUc/FQYyeB+teR9HezzLGZSq19AgWJEy95AYmhWuYrWIuJxVEdC9gpLA+Bi4xGMulmQcx2aqEXoV+nUKnrLCY9qJpuzEdiXGVVvc1hSSmP8xqsRmEQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 14, 2023 at 11:43=E2=80=AFAM Matthew Wilcox wrote: > > On Fri, Apr 14, 2023 at 11:00:43AM -0700, Suren Baghdasaryan wrote: > > When page fault is handled under VMA lock protection, all swap page > > faults are retried with mmap_lock because folio_lock_or_retry > > implementation has to drop and reacquire mmap_lock if folio could > > not be immediately locked. > > Instead of retrying all swapped page faults, retry only when folio > > locking fails. > > Reviewed-by: Matthew Wilcox (Oracle) Thank you for the reviews! > > Let's just review what can now be handled under the VMA lock instead of > the mmap_lock, in case somebody knows better than me that it's not safe. > > - We can call migration_entry_wait(). This will wait for PG_locked to > become clear (in migration_entry_wait_on_locked()). As previously > discussed offline, I think this is safe to do while holding the VMA > locked. > - We can call remove_device_exclusive_entry(). That calls > folio_lock_or_retry(), which will fail if it can't get the VMA lock. > - We can call pgmap->ops->migrate_to_ram(). Perhaps somebody familiar > with Nouveau and amdkfd could comment on how safe this is? > - I believe we can't call handle_pte_marker() because we exclude UFFD > VMAs earlier. > - We can call swap_readpage() if we allocate a new folio. I haven't > traced through all this code to tell if it's OK. > > So ... I believe this is all OK, but we're definitely now willing to > wait for I/O from the swap device while holding the VMA lock when we > weren't before. And maybe we should make a bigger deal of it in the > changelog. > > And maybe we shouldn't just be failing the folio_lock_or_retry(), > maybe we should be waiting for the folio lock with the VMA locked. Wouldn't that cause holding the VMA lock for the duration of swap I/O (something you said we want to avoid in the previous paragraph) and effectively undo d065bd810b6d ("mm: retry page fault when blocking on disk transfer") for VMA locks? >