[{"id":3684669,"web_url":"http://patchwork.ozlabs.org/comment/3684669/","msgid":"<afNM-gIqxpyJ6ro7@casper.infradead.org>","date":"2026-04-30T12:37:14","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":70855,"url":"http://patchwork.ozlabs.org/api/people/70855/","name":"Matthew Wilcox","email":"willy@infradead.org"},"content":"On Thu, Apr 30, 2026 at 12:04:22PM +0800, Barry Song (Xiaomi) wrote:\n> (1) If we need to wait for I/O completion, we still drop the per-VMA lock, as\n> current page fault handling already does. Holding it for too long may introduce\n> various priority inversion issues on mobile devices. After I/O completes, we\n> retry the page fault with the per-VMA lock, rather than falling back to\n> mmap_lock.\n\nYou're going to have to do better than that.  You know I hate the\nadditional complexity you're adding.  You need to explain why my idea of\nripping out all the complexity now that we have per-VMA locks doesn't\nwork.","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20343-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=OVEuy04Z;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20343-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=\"2001:8b0:10b:1236::1\"","lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=OVEuy04Z;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=infradead.org\n (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org;\n envelope-from=willy@infradead.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g5twt3VXNz1xqf\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 30 Apr 2026 22:37:34 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g5twt2NjXz2xpp;\n\tThu, 30 Apr 2026 22:37:34 +1000 (AEST)","from casper.infradead.org (casper.infradead.org\n [IPv6:2001:8b0:10b:1236::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g5tws46W2z2xnt\n\tfor <linuxppc-dev@lists.ozlabs.org>; Thu, 30 Apr 2026 22:37:33 +1000 (AEST)","from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red\n Hat Linux))\n\tid 1wIQdn-00000007Dwg-0sn0;\n\tThu, 30 Apr 2026 12:37:15 +0000"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777552654;\n\tcv=none;\n b=ay5tB4mfotaz3EU6MVq01jHWswtngyr6LGi0vIfxjXu7wMjYelzbUIEicGcToPZhxjD6ilEMxIqLFv841EHm43FASgIGtwqjtLmusNmdViouVNeInvA3uwhIM9mId6qRgntKEMunkzxhCQGkr0aXWYyM6L9KWAhdy3va8T2oxo5WN2S+PAsLZ7RX/oAjyaflyfhYxIRPOYE6W9TNAuBEq7o2E72zIBxvbkMmGxvwZj4CS6YPZ6gFmP8JFK2H0JrNmGrDcnL6Pff0r4uNIsYTJkZ85gbIYhNLzH7oGDQXSEqmL6+XX7dON+rUTtNtf4Ofi2WWWIlwiD0Ecs/mHiOnuA==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777552654; c=relaxed/relaxed;\n\tbh=z/YmOm364MLgKTekAQcMcyvI8WeWgw/tah25yx/smkI=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=R5HSmLxBkR7BVtQVMH9aQzro14E4BC3sHy8kcXPzEi1gytNK7LTBDWzAhoHfrSLjIAmbgvZSyiIICpOA9rFqbI57VQfvEsfGBVllV9tP26K38EVTT4lOjjHVehmjOA7xqdegsgDRuizj9YF+ziLXqhbwKXIWk8HX41FwRGMqXvfwOYLrcJ1rpQ3QcKAdqXWAOYWRRor7918NfgJV3TihjheAYX90AmQehKfrPbjuf27GF3YSkH4JCIUv2rRsOy3h/Wpl3zr0MBN8UlWXUFfwq1FfwAZrbrE9MR2UnaEJbS8seNMyJD4Q/t3Q+5+FhfX2V/TTJ7aGfR+P644IfvsiJQ==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n dkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=OVEuy04Z; dkim-atps=neutral;\n spf=none (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org;\n envelope-from=willy@infradead.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=infradead.org","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:\n\tReferences:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description;\n\tbh=z/YmOm364MLgKTekAQcMcyvI8WeWgw/tah25yx/smkI=; b=OVEuy04ZJAcBaKwk8cxrvq7Tt5\n\tXT82G1jqIw0PkdnsdUVlw+7QCza/twzfpnsx2kAqSxg7PTBm0kBexRmE2xwQdNMnRyEnteCqgWzIn\n\tpGkT+4EL2ASd9E3W3zW7yYDg3jwhiv9VQjK8KHyhy+eeJpz4dqkaLDP6PuXP1J2eRrmKWTk8F9tKW\n\tCawTIBqH87INZkKlSIMhv2zjWwFJnSYo+4xe4HesOWqi4rik/G82R6PqrkV5YTcbPWHu29MwOaGgj\n\tjzKa0vAXrEAUkOYciTPNLGggQqRFBNNvsXY3E40Q+hwIcMj9vZmSiwG6RsfdSJ+eO9OpzQbCzsngB\n\twKLRaGvg==;","Date":"Thu, 30 Apr 2026 13:37:14 +0100","From":"Matthew Wilcox <willy@infradead.org>","To":"\"Barry Song (Xiaomi)\" <baohua@kernel.org>","Cc":"akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org,\n\tljs@kernel.org, liam@infradead.org, vbabka@kernel.org,\n\trppt@kernel.org, surenb@google.com, mhocko@suse.com, jack@suse.cz,\n\tpfalcato@suse.de, wanglian@kylinos.cn, chentao@kylinos.cn,\n\tlianux.mm@gmail.com, kunwu.chan@gmail.com, liyangouwen1@oppo.com,\n\tchrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com,\n\tnphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tloongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,\n\tlinux-riscv@lists.infradead.org, linux-s390@vger.kernel.org","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","Message-ID":"<afNM-gIqxpyJ6ro7@casper.infradead.org>","References":"<20260430040427.4672-1-baohua@kernel.org>","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260430040427.4672-1-baohua@kernel.org>","X-Spam-Status":"No, score=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3684974,"web_url":"http://patchwork.ozlabs.org/comment/3684974/","msgid":"<CAGsJ_4w0qcYmukHqsyRd0jomoyYkJjOt8b-Cgp53BgP-8QQghw@mail.gmail.com>","date":"2026-04-30T22:49:58","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":48512,"url":"http://patchwork.ozlabs.org/api/people/48512/","name":"Barry Song","email":"baohua@kernel.org"},"content":"On Thu, Apr 30, 2026 at 8:37 PM Matthew Wilcox <willy@infradead.org> wrote:\n>\n> On Thu, Apr 30, 2026 at 12:04:22PM +0800, Barry Song (Xiaomi) wrote:\n> > (1) If we need to wait for I/O completion, we still drop the per-VMA lock, as\n> > current page fault handling already does. Holding it for too long may introduce\n> > various priority inversion issues on mobile devices. After I/O completes, we\n> > retry the page fault with the per-VMA lock, rather than falling back to\n> > mmap_lock.\n>\n> You're going to have to do better than that.  You know I hate the\n> additional complexity you're adding.  You need to explain why my idea of\n> ripping out all the complexity now that we have per-VMA locks doesn't\n> work.\n\nYep, I know you don’t like the added complexity, but I would rather prioritize\nuser experience over simplicity. Let me try to explain in more detail.\n\n1. There is no deterministic latency for I/O completion. It depends on\nboth the hardware and the software stack (bio/request queues and the\nblock scheduler). Sometimes the latency is short; at other times it can\nbe quite long. In such cases, a high-priority thread performing operations\nsuch as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait\nfor an unpredictable amount of time. For example, if low-priority tasks\ntrigger page faults and issue low-priority I/O, a high-priority task\nrequiring the write lock may end up waiting for an unknown amount of time,\ndepending on the block layer and filesystem behavior.\n\nAs a result, high-priority tasks are exposed to unpredictable I/O latency\nintroduced by many low-priority tasks that may generate a large number of\npage faults.\n\nOn Android, latency in certain tasks can significantly affect user experience,\nsuch as interactive threads. Priority inversion is particularly problematic and\nshould be avoided, especially since we have no clear bound on how long we may\nhave to wait for I/O from other tasks.\n\nMeanwhile, priority inversion can propagate through a long chain: a writer\nwaiting on I/O from multiple concurrent page faults may end up blocking other\nwriters and readers as well. A long-waiting writer can also amplify\nmmap_lock contention, which we still rely on in many cases.\n\n2. VMA sizes can be highly uneven: some VMAs may be very large while others are\nsmall. We used to have many reasons to release mmap_lock when we did not have a\nper-VMA lock. Since VMA sizes are not uniform, those same considerations may\nstill apply to the per-VMA lock when a small number of VMAs account for most\nof a process’s address space. I recall that Suren also mentioned this[1].\n\nSo I would prefer that we hold only the per-VMA lock and avoid retrying the\npage fault when we are reasonably sure that I/O has already completed and we\nare only waiting for short-lived conditions. Uncertainties in the block layer,\nfilesystem, and GC behavior, as well as latency-induced priority inversion\nchains and potentially amplified mmap_lock contention, can significantly hurt\nAndroid user experience.\n\n[1] https://lore.kernel.org/linux-mm/CAJuCfpFVQJtvbj5fV2fmm4APhNZDL1qPg-YExw7gO1pmngC3Rw@mail.gmail.com/\n\nThanks\nBarry","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20348-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=dBXZ2oY8;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=112.213.38.117; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20348-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=\"2600:3c0a:e001:78e:0:1991:8:25\"","lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=dBXZ2oY8;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org\n (client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org;\n envelope-from=baohua@kernel.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g68Wz5KP9z1yGq\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 01 May 2026 08:50:22 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g68Wx1bZ8z2xH7;\n\tFri, 01 May 2026 08:50:21 +1000 (AEST)","from sea.source.kernel.org (sea.source.kernel.org\n [IPv6:2600:3c0a:e001:78e:0:1991:8:25])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g68Wt6F3Sz2xGY\n\tfor <linuxppc-dev@lists.ozlabs.org>; Fri, 01 May 2026 08:50:18 +1000 (AEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby sea.source.kernel.org (Postfix) with ESMTP id 277C1444D4\n\tfor <linuxppc-dev@lists.ozlabs.org>; Thu, 30 Apr 2026 22:50:12 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 0DFE2C2BCF5\n\tfor <linuxppc-dev@lists.ozlabs.org>; Thu, 30 Apr 2026 22:50:12 +0000 (UTC)","by mail-qv1-f51.google.com with SMTP id\n 6a1803df08f44-89f1e767f92so13294906d6.2\n        for <linuxppc-dev@lists.ozlabs.org>;\n Thu, 30 Apr 2026 15:50:12 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777589421;\n\tcv=none;\n b=Knp465nYvFJ5y8hYHhRwAv8zxsgTqck7VCqJgb7fk/S0hTA8e9D2R88rqxa/z+s1uQeK4HHpzBsCiUi4Ne5hfcKWn2+iqy2ZGFw6FmKxSBFpgCgyS6xEoJwxeqy7W4v+AplHr9dVckhZP+wuf9ncqv1EwMovRH1vjGa0oLAISB56SowN4YZVyxuhpVBbpu7YWuo4AORMdcmbDjDYH/SuZru5a8no7JD+Y60lcFvk4dZqI8jXrr3Pa8UfWnGtLkHHVX3BEfc9w0ZYg5QU13otM+xuN7JSIEacLY/cbt5QiDm3eYDgioSfgezt/F3NDNtPxEjwHBtw3j12zQrMuC4Iyg==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777589421; c=relaxed/relaxed;\n\tbh=nyIAHMCO2XSEKhIrNQWe82Ob3aOc1tSJG1laNn5OlYg=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=Qj6c5mkI4ptKgLBmX70V0yFb5ddvlaOw9ezJaU08ZdaUcWxtKu0HUNGv+EL0Lc3k4aBI6tSHy6vfZKZpJg6mKao9Wcnhu2ziqghVeWPhnUM+5AHakQnxPFOA4b+y2a25IJnPk0Eohemys7D0Rv+zLEEtmcIKYSZCWlyttBYphxhYKYjyKhiWWaE2xaXy/5HG9sc34A0c1SYhAhB33+TjfdRmBhnpf0poM+vDbrcU5Z1lSSA6ccZ8d8prWe4vkA+thafXKvKyQ3O0r8Kc7DZPVoJk6d04wc6z02cn0Qsz9YcCX81jUBXABgOksqO1RjC5Dkfxb8tZftdBDfD+Et3+Gw==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org;\n dkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=dBXZ2oY8; dkim-atps=neutral;\n spf=pass (client-ip=2600:3c0a:e001:78e:0:1991:8:25;\n helo=sea.source.kernel.org; envelope-from=baohua@kernel.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777589412;\n\tbh=EwR29NH5HVcLbVvA5ViI57mAmHT3DBCHHsLg0gf7Cic=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=dBXZ2oY8bPD0T7Gd4Of7GUZOb84hKrxvQlNnKxyNarxinIUzFHyBM9s+qDR4U9LPp\n\t +Hc8F8WFDCZQqqo+npT5fUj0txmJKGzK48NWf+a5HFI0nv9pWEpw/7Z7MiE/1dYHmC\n\t B12UZdt6YCq68u/rqEbIGy9P6FZiNurFRNlp3PZg9yOU7Gob8iSTSCXSUBOt2JbkAC\n\t Fwp47SUVHvHazO57YaIALODnh+Wg6M0vRWtAdK9btMOZWw3UF7+id1X74wqvWjE3jS\n\t uK3gMgeJ00mb08GoZiRN6AIHhiPzdeZPoa0S7aYZkNoWzKQDPWrMHLEaBFdV5I1od5\n\t XDQUtFcs0lleA==","X-Forwarded-Encrypted":"i=1;\n AFNElJ+1d2pEQ/vMztEYz5iF46+biRKuQIRBzoBE5BsM7CF5Ie08f9PYqWuhYr3++E8OwZ52vicVqFu6ZiNx/Ks=@lists.ozlabs.org","X-Gm-Message-State":"AOJu0Yzw8+S5FGPLWFWSUc9fWzkvwSlja5W4mSei6c8PuhVldRSEoymA\n\tvrwTjT1wi9QegYToAnwCe8ONH5pcobjRvq3SAqRFObpMsetbd8KNt/lgpnBXwx3gdfW6CKCbdDH\n\tJZPhW0yNM4C4ZbdfNp1e0GXQcNtYLUOg=","X-Received":"by 2002:a05:6214:3f81:b0:899:f092:9da with SMTP id\n 6a1803df08f44-8b3fe7bd179mr81439146d6.28.1777589410935; Thu, 30 Apr 2026\n 15:50:10 -0700 (PDT)","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","References":"<20260430040427.4672-1-baohua@kernel.org>\n <afNM-gIqxpyJ6ro7@casper.infradead.org>","In-Reply-To":"<afNM-gIqxpyJ6ro7@casper.infradead.org>","From":"Barry Song <baohua@kernel.org>","Date":"Fri, 1 May 2026 06:49:58 +0800","X-Gmail-Original-Message-ID":"\n <CAGsJ_4w0qcYmukHqsyRd0jomoyYkJjOt8b-Cgp53BgP-8QQghw@mail.gmail.com>","X-Gm-Features":"AVHnY4LNqeENq1Hu8yfE3Ha6l6qy4pcPzLhOvHSM0QbVepERNdbmRODWwcwvH-c","Message-ID":"\n <CAGsJ_4w0qcYmukHqsyRd0jomoyYkJjOt8b-Cgp53BgP-8QQghw@mail.gmail.com>","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","To":"Matthew Wilcox <willy@infradead.org>","Cc":"akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org,\n\tljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org,\n\tsurenb@google.com, mhocko@suse.com, jack@suse.cz, pfalcato@suse.de,\n\twanglian@kylinos.cn, chentao@kylinos.cn, lianux.mm@gmail.com,\n\tkunwu.chan@gmail.com, liyangouwen1@oppo.com, chrisl@kernel.org,\n\tkasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com,\n\tbhe@redhat.com, youngjun.park@lge.com, linux-arm-kernel@lists.infradead.org,\n\tlinux-kernel@vger.kernel.org, loongarch@lists.linux.dev,\n\tlinuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,\n\tlinux-s390@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3685150,"web_url":"http://patchwork.ozlabs.org/comment/3685150/","msgid":"<afS_L-5XeWIldTXA@casper.infradead.org>","date":"2026-05-01T14:56:47","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":70855,"url":"http://patchwork.ozlabs.org/api/people/70855/","name":"Matthew Wilcox","email":"willy@infradead.org"},"content":"On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:\n> 1. There is no deterministic latency for I/O completion. It depends on\n> both the hardware and the software stack (bio/request queues and the\n> block scheduler). Sometimes the latency is short; at other times it can\n> be quite long. In such cases, a high-priority thread performing operations\n> such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait\n> for an unpredictable amount of time.\n\nBut does that actually happen?  I find it hard to believe that thread A\nunmaps a VMA while thread B is in the middle of taking a page fault in\nthat same VMA.  mprotect() and madvise() are more likely to happen, but\nit still seems really unlikely to me.","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20367-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=Er8GF8z4;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20367-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=\"2001:8b0:10b:1236::1\"","lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=Er8GF8z4;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=infradead.org\n (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org;\n envelope-from=willy@infradead.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6Yzr6JQJz1yHZ\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 02 May 2026 00:57:28 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g6Yzr57FCz309S;\n\tSat, 02 May 2026 00:57:28 +1000 (AEST)","from casper.infradead.org (casper.infradead.org\n [IPv6:2001:8b0:10b:1236::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g6Yzj6ygFz2xnZ\n\tfor <linuxppc-dev@lists.ozlabs.org>; Sat, 02 May 2026 00:57:19 +1000 (AEST)","from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red\n Hat Linux))\n\tid 1wIpIN-00000008wbR-3iIK;\n\tFri, 01 May 2026 14:56:48 +0000"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777647448;\n\tcv=none;\n b=SqCRhCMRCv3s29eAXYHsuu9Fh3yvNEjU13X2Jcfab4mcJtllup0agHx6dzalacsqDl/ej2/skVtGVTIaT1YORij7MzzRVFDIJr48LNIMgfBoW/EjkZmyHb6v0qZ5SWkFwdrLk84WTxej6d/GFetW1fNLIQkQoxB72mcxx0s0K6p3K9PRzvx9ZevJ5cePWb4J3RuDNpG7PaTWt+bsz6cLpCVrB1RQ3uE+oWLqHNhAZwWUk5FhIC0cIxcMtqEYuBNsqsby25cDtxrzK7118flh7S57XRSvvynwAthLXxipdO1cpCRp91eosB+QOKSIrLMRuSuncBNP8SXE27p2B6DVtg==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777647448; c=relaxed/relaxed;\n\tbh=GWaEOZ6T8RZshC5VNeX+VR+c38seOstsZgFtVZK1Yb0=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=MNRn7PD7RdHdhGXDQIe2Fhe0gE5/Py7AjOGO7TorRluX2QA6a8PvVQrV4n780qClEz4somQuKCJJFW79SZfxwTi9nitXHjoPZmXP8fpU4yBwKtK2xubCFiLGYQ7LyAY9OjcVfDEgT7fOXiPiFO0Ysxg06hYgs7yIfB1avotU+0gV62zZEAa6FIxdEJnPTuDN90eL9zgFeDbwRtAKFMUzy/TAP/I0TpMkczRF5lft2r4KwCZWiOvkoKl4blvXjGKqoq9az8obTNW4BJFh5lxUPN/SO61MmQkw84HyuY9FzkDAPYb08nhVTIlIg9lJY8rbtdO2eqEaYSzrrAqjNz0uBA==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n dkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=Er8GF8z4; dkim-atps=neutral;\n spf=none (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org;\n envelope-from=willy@infradead.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=infradead.org","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:\n\tReferences:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description;\n\tbh=GWaEOZ6T8RZshC5VNeX+VR+c38seOstsZgFtVZK1Yb0=; b=Er8GF8z4i4fcdoqldcSz6UdIrK\n\t0uV2fMmb401OPsbWUDQlEgY0WImYvRoaOS/51Kt7cci4PwM0IwWZmDRUbGXw7O9IkTUTcXx4Dq2Om\n\t1ySnKP5ZPsmA0cdTKwQEUsbejJKOkDxp+xsnqOc9et7bCG9WzZFKFYNxcz4UjijcH9lNIaYGg9axV\n\tD8CvZuRnVnBvGs0WeFCpwaRxMrcj+ZmM+kVA2Q+aDmR35tDfpqtDlNjfzVDU0ieNT7dT3nkuFY8KO\n\toBaeuIlQkfSbM8D3+gtqA/Kl4BULEQcG2OPtDBswRpN88NbjoIlZE7bl29JItAlrzNVWRNazfWERT\n\tlB1uWyaw==;","Date":"Fri, 1 May 2026 15:56:47 +0100","From":"Matthew Wilcox <willy@infradead.org>","To":"Barry Song <baohua@kernel.org>","Cc":"akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org,\n\tljs@kernel.org, liam@infradead.org, vbabka@kernel.org,\n\trppt@kernel.org, surenb@google.com, mhocko@suse.com, jack@suse.cz,\n\tpfalcato@suse.de, wanglian@kylinos.cn, chentao@kylinos.cn,\n\tlianux.mm@gmail.com, kunwu.chan@gmail.com, liyangouwen1@oppo.com,\n\tchrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com,\n\tnphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tloongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,\n\tlinux-riscv@lists.infradead.org, linux-s390@vger.kernel.org","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","Message-ID":"<afS_L-5XeWIldTXA@casper.infradead.org>","References":"<20260430040427.4672-1-baohua@kernel.org>\n <afNM-gIqxpyJ6ro7@casper.infradead.org>\n <CAGsJ_4w0qcYmukHqsyRd0jomoyYkJjOt8b-Cgp53BgP-8QQghw@mail.gmail.com>","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"\n <CAGsJ_4w0qcYmukHqsyRd0jomoyYkJjOt8b-Cgp53BgP-8QQghw@mail.gmail.com>","X-Spam-Status":"No, score=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3685162,"web_url":"http://patchwork.ozlabs.org/comment/3685162/","msgid":"<afTKsSj0i-ZkRZN5@lucifer>","date":"2026-05-01T15:52:12","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":92784,"url":"http://patchwork.ozlabs.org/api/people/92784/","name":"Lorenzo Stoakes","email":"ljs@kernel.org"},"content":"On Thu, Apr 30, 2026 at 01:37:14PM +0100, Matthew Wilcox wrote:\n> On Thu, Apr 30, 2026 at 12:04:22PM +0800, Barry Song (Xiaomi) wrote:\n> > (1) If we need to wait for I/O completion, we still drop the per-VMA lock, as\n> > current page fault handling already does. Holding it for too long may introduce\n> > various priority inversion issues on mobile devices. After I/O completes, we\n> > retry the page fault with the per-VMA lock, rather than falling back to\n> > mmap_lock.\n>\n> You're going to have to do better than that.  You know I hate the\n> additional complexity you're adding.  You need to explain why my idea of\n> ripping out all the complexity now that we have per-VMA locks doesn't\n> work.\n\nAfter a brief eyeball I share Matthew's assessment, I really don't like this\nseries, it's piling on complexity for what seem like niche cases.\n\nWe already have enough weirdness in fault code honestly.\n\nLet's maybe discuss at LSF if you're attending?\n\nI will try to have a more thorough look through when I get a chance.\n\nThanks, Lorenzo","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20368-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=IVDd9j10;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20368-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=172.105.4.254","lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=IVDd9j10;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org\n (client-ip=172.105.4.254; helo=tor.source.kernel.org;\n envelope-from=ljs@kernel.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6bCM2Q6Rz1y04\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 02 May 2026 01:52:31 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g6bCF38tsz2xWY;\n\tSat, 02 May 2026 01:52:25 +1000 (AEST)","from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g6bCD1nrRz2xBb\n\tfor <linuxppc-dev@lists.ozlabs.org>; Sat, 02 May 2026 01:52:24 +1000 (AEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby tor.source.kernel.org (Postfix) with ESMTP id 5DF83600AE;\n\tFri,  1 May 2026 15:52:21 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 578D9C2BCB4;\n\tFri,  1 May 2026 15:52:16 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777650745;\n\tcv=none;\n b=O64PV2X1+aLr+PfvecLhcpH+coV0lO3bIb0Nzu49qnX4Y/P4WmLjehAErbjxuYegAx9DMVhIjHw17shDXP0PVXLah+pZ+yWyVaIY7XWM4NwLJRhA8JwFWvG7QouEJ3x53VdCNeTAHmviGVJNLrl17fFicyB8n/AyRdkocgE9eX0WC9EsbjV1ZuL/0BWIqbGKuQ+LkUl6m7o+ZswCYzDKM9UjVUxAvYwsXEwfWvQhwkc95HAdlF3e9qB6lsZUKWkPxbshJWxCZDKgLZtek65p7Xiyp5dJBhLn3aJifpkZLmJd0wH+pCwVrGud0wCPuQ4HqWcxRwUHcLFH0c8yziVUVw==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777650745; c=relaxed/relaxed;\n\tbh=SiF4i7SeB+vqQpOzTdzc7LyjPQDII4G9BWeiAEqxhGE=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=DcyWjZQyhQcsGmjB6Rzb8Q2141NzopFAYf1btvwqtXuLCc8bhdTIbSCu0bUjHsxyf+ktKHAZpJ1PeF8PVLBLXvhKokCyU4aZsDkmXkCdT6BhSiwjeSQrKmIqj0y40IBQWfjlzkNcsizoeMvTB7PjfKJeiGWyjgXXWu1sjkAsOj8AWRDFoyD0w+kp7ks6+N9VAH7cC3whrIZxbpKskmyrXpHqucRVt7Ah7GABZzXf7an7kxBAIEMvbx4vgSM82gSD+gvN42ICaNTaZ6q3b9D8ocEsy8fI+bHZCVQR+Nqs1N/EmdbZ6Fb9S3WkbRlQDK7oagdb/fY4EdtVBpDoD+ru2Q==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org;\n dkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=IVDd9j10; dkim-atps=neutral;\n spf=pass (client-ip=172.105.4.254; helo=tor.source.kernel.org;\n envelope-from=ljs@kernel.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777650741;\n\tbh=CmRbcbTi+OjVPZtnCXwufH2SPkRkS5oJkc2YfZ1djM0=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=IVDd9j10pzEBSdRC4+QeFj4BgrGtGegXqADT53FcQUjMhslsOR/0b8M/SeBRUjbiL\n\t U2fYt86IaWaPqn4mV1onqa61I1SUk7HLNDW/omvLoBf0BH4n82Nt8SShUszHOEgWX+\n\t Yg2s+/jyz3VDnqKEVso8YuKRhMIWmw5AZKuu313vA5DlmyJ/Rx3fmNczFEGG/bRD5C\n\t eqUXB71O0/nCiiPJ8qZcNkawkQKohpdSSJ4uA0FZNvaLfCO6RUdrocyE/W1A7fSAIz\n\t Hbt9kjA297YFDx/3kqUo5yAmQtYP02v7yShDf43ds+6qzWhvd82x48N7/jTN1fhgjc\n\t 65/sBiyDMsG6w==","Date":"Fri, 1 May 2026 16:52:12 +0100","From":"Lorenzo Stoakes <ljs@kernel.org>","To":"\"Barry Song (Xiaomi)\" <baohua@kernel.org>","Cc":"Matthew Wilcox <willy@infradead.org>, akpm@linux-foundation.org,\n\tlinux-mm@kvack.org, david@kernel.org, liam@infradead.org, vbabka@kernel.org,\n\trppt@kernel.org, surenb@google.com, mhocko@suse.com, jack@suse.cz,\n\tpfalcato@suse.de, wanglian@kylinos.cn, chentao@kylinos.cn,\n lianux.mm@gmail.com,\n\tkunwu.chan@gmail.com, liyangouwen1@oppo.com, chrisl@kernel.org,\n kasong@tencent.com,\n\tshikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com,\n youngjun.park@lge.com,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n loongarch@lists.linux.dev,\n\tlinuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,\n linux-s390@vger.kernel.org","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","Message-ID":"<afTKsSj0i-ZkRZN5@lucifer>","References":"<20260430040427.4672-1-baohua@kernel.org>\n <afNM-gIqxpyJ6ro7@casper.infradead.org>","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<afNM-gIqxpyJ6ro7@casper.infradead.org>","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3685165,"web_url":"http://patchwork.ozlabs.org/comment/3685165/","msgid":"<afTPamwDbtY_tgk_@casper.infradead.org>","date":"2026-05-01T16:06:02","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":70855,"url":"http://patchwork.ozlabs.org/api/people/70855/","name":"Matthew Wilcox","email":"willy@infradead.org"},"content":"On Fri, May 01, 2026 at 04:52:12PM +0100, Lorenzo Stoakes wrote:\n> After a brief eyeball I share Matthew's assessment, I really don't like this\n> series, it's piling on complexity for what seem like niche cases.\n\nI don't think they're niche cases ... I think it's a real problem.\nWhile our current code performs better for this workload than the\npre-vma-lock code did, it doesn't perform as well as it could.\n\n> We already have enough weirdness in fault code honestly.\n> \n> Let's maybe discuss at LSF if you're attending?\n\nNot only is he attending, there's a topic scheduled (currently 10:30 on\nWednesday).","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20369-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=WFSklIdw;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20369-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=\"2001:8b0:10b:1236::1\"","lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=WFSklIdw;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=infradead.org\n (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org;\n envelope-from=willy@infradead.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6bWd0wckz1y04\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 02 May 2026 02:06:37 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g6bWc2yLzz2xWY;\n\tSat, 02 May 2026 02:06:36 +1000 (AEST)","from casper.infradead.org (casper.infradead.org\n [IPv6:2001:8b0:10b:1236::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g6bWZ1423z2xBb\n\tfor <linuxppc-dev@lists.ozlabs.org>; Sat, 02 May 2026 02:06:30 +1000 (AEST)","from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red\n Hat Linux))\n\tid 1wIqNP-000000091GR-0gTr;\n\tFri, 01 May 2026 16:06:03 +0000"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777651596;\n\tcv=none;\n b=KNYyF+JNmVEE2R6B1dHvee+spbiutzMdGzakkYzyUXgePsKo/BiUPt+8G7l8EU8wENC5BRJLORI6n2OrZH5AYUDRKtdIHViLERGeE2g0sCa2C2yOqXWOnTvf0bHQ5yvxdaTrgSBQggcn6KgdBNjXmQX2EY/YB5W2dSPzW3ouseAK3dqhYSg83R+AvAxx+jq6+4ICwo1OP7fzmelbR0ZrcQuO6XbQdcOdaUut5mqkHBZaxiLO7XvFagd0aJ7JtgRU/5qUNZqa3r7jX+vsU/Gc2XlDj8s5YHwCK64iequduS75gdF7Kw2vGT7IGQpio0pVtHTDXZGogT2TQiyYDsCBeg==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777651596; c=relaxed/relaxed;\n\tbh=HCOnYxAIgiWvR0Bg9Z3oQP7NtLB+AbBygf9mhxuV9oQ=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=Dk4DTI35Lx6SuEr6kQID4r2SyxZjONz1FGvNNnpszR4HyCLUoVOTVdW85bd7a/rx+Ia5S3/4wwQ53NaExyXy9Yu3c2zJUSdq8aK6hocAdH7L9piW6V+nCxrk6fcKc6yw7ytO7/I5N42J3ofaz/MkrbIx3YBD4ctP3UfiG02L65CLymzWWT8iq6eSVtppnkEGxYrW/t/ZqUr8KC0/1B02z8CFljdPUTizbP+/vg6NnFqPyJHoB7ydMWHO0kmTr3hk2YQrJjbTQIohDVzhK4zAgdisiSHfEDBiPiDrCVbwfUmw6di8RddRv40NRnf9JkydYYdg0STxsPjkW84u0dWKjw==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n dkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=WFSklIdw; dkim-atps=neutral;\n spf=none (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org;\n envelope-from=willy@infradead.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=infradead.org","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:\n\tReferences:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description;\n\tbh=HCOnYxAIgiWvR0Bg9Z3oQP7NtLB+AbBygf9mhxuV9oQ=; b=WFSklIdwMHQLNKo0hSt8FUEdor\n\t8PWAceSimwETsGI72z85Zv4wA/tsNlycLa8f6sQG/Aw6w8RnhXi0Af5mjum18LwybDyAvb1+Uxh9f\n\tEq5T7ug+O10pWFjftTfOmniisY01PyMq7+2peSvdamJ+AAvHZRIQTazUoIUXsplGALDIdW/42jR8p\n\tU9uUO/7PltvaGp/EEhx55GmxP2PijjP4N8jL7/SdhnE0m0apJTc1yrnAE6WrXuehMZUnK54FJ0YvF\n\tM5qMff6H54NLzO+TN+U51R/JiQDmY0k5rW4FXREurwavyb9AebilT1ieN2HbK2yQvGHgLvA2FHU0e\n\trgYRe6xw==;","Date":"Fri, 1 May 2026 17:06:02 +0100","From":"Matthew Wilcox <willy@infradead.org>","To":"Lorenzo Stoakes <ljs@kernel.org>","Cc":"\"Barry Song (Xiaomi)\" <baohua@kernel.org>, akpm@linux-foundation.org,\n\tlinux-mm@kvack.org, david@kernel.org, liam@infradead.org,\n\tvbabka@kernel.org, rppt@kernel.org, surenb@google.com,\n\tmhocko@suse.com, jack@suse.cz, pfalcato@suse.de,\n\twanglian@kylinos.cn, chentao@kylinos.cn, lianux.mm@gmail.com,\n\tkunwu.chan@gmail.com, liyangouwen1@oppo.com, chrisl@kernel.org,\n\tkasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com,\n\tbhe@redhat.com, youngjun.park@lge.com,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tloongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,\n\tlinux-riscv@lists.infradead.org, linux-s390@vger.kernel.org","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","Message-ID":"<afTPamwDbtY_tgk_@casper.infradead.org>","References":"<20260430040427.4672-1-baohua@kernel.org>\n <afNM-gIqxpyJ6ro7@casper.infradead.org>\n <afTKsSj0i-ZkRZN5@lucifer>","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<afTKsSj0i-ZkRZN5@lucifer>","X-Spam-Status":"No, score=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3685183,"web_url":"http://patchwork.ozlabs.org/comment/3685183/","msgid":"<afTeKp90wGNixIOX@lucifer>","date":"2026-05-01T17:09:30","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":92784,"url":"http://patchwork.ozlabs.org/api/people/92784/","name":"Lorenzo Stoakes","email":"ljs@kernel.org"},"content":"On Fri, May 01, 2026 at 05:06:02PM +0100, Matthew Wilcox wrote:\n> On Fri, May 01, 2026 at 04:52:12PM +0100, Lorenzo Stoakes wrote:\n> > After a brief eyeball I share Matthew's assessment, I really don't like this\n> > series, it's piling on complexity for what seem like niche cases.\n>\n> I don't think they're niche cases ... I think it's a real problem.\n> While our current code performs better for this workload than the\n> pre-vma-lock code did, it doesn't perform as well as it could.\n>\n> > We already have enough weirdness in fault code honestly.\n> >\n> > Let's maybe discuss at LSF if you're attending?\n>\n> Not only is he attending, there's a topic scheduled (currently 10:30 on\n> Wednesday).\n\nWell then, let's revisit this in person in Zagreb :)\n\nCheers, Lorenzo","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20371-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=OX2L1x4x;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20371-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=\"2600:3c0a:e001:78e:0:1991:8:25\"","lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=OX2L1x4x;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org\n (client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org;\n envelope-from=ljs@kernel.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6cwZ5HFKz1xvV\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 02 May 2026 03:09:50 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g6cwS0Gtgz2yjx;\n\tSat, 02 May 2026 03:09:44 +1000 (AEST)","from sea.source.kernel.org (sea.source.kernel.org\n [IPv6:2600:3c0a:e001:78e:0:1991:8:25])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g6cwQ3lzZz2xGC\n\tfor <linuxppc-dev@lists.ozlabs.org>; Sat, 02 May 2026 03:09:42 +1000 (AEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby sea.source.kernel.org (Postfix) with ESMTP id DE7D143E9A;\n\tFri,  1 May 2026 17:09:39 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 7EC2AC2BCB4;\n\tFri,  1 May 2026 17:09:34 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777655383;\n\tcv=none;\n b=XkiQkfG2dou2sdTUdj/d1Fb7ZIOLVIuHdn+f9+RD+ohHUUeM2R0IfvNqrhphLy1WliXDQJdHrHYDfFGvfr/T2QqNUPO7/XclX+jMOfVuJzabHgdJUAocNNVyTAzPCup4SC3VwDjj8klUnKZ6jbKz1xEToKG6bMMpfdoxi7CyTjPOr8aJ6a1VCcoruVYODvbsPnRvO0AU+D2Sh44YIcptd1gtC0DyrxqU0ZTsuPyniOV52b1PE1H8DSfRNL2TYzJjO4/pWPbxx/6WMJX24DdfgvOeRDDVcjhLq5TvuSKUjgKHWAa3OqIQYm2EWsyH1Z6MmUyX8GDfz/b22f7lrxn2Sg==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777655383; c=relaxed/relaxed;\n\tbh=aCKpiD8Crlk0uEQZs9vyjBCgLqxVn32/cxl6Y0AtRGE=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=fCwMA9eR+PSBMsfVa48R4bCsWDUqXiLqfy/cRAWhFkeE18CIrDB3UmH3380nok3l3dzJGegwKnfGYsmICMHfenhBSjmQStV0JdlmXebqyAI4EgzrggHDV6OiKUDuOSUXj9GD+Wug8AReVRQfjXap606VQTfY9sa4XiXCLncLznSXK77XkCvFpLZb+1el1CeFXbScZ7Ryq7CbDAE2nkH8H3okut+odsr2D6WL5xX7hJGfZMo1l4coHP2akI7jJgQhHUSw1j3vFXTHFvuV+rGTdZTYGfVGid9T71xSw0EZgoi2OWcxwWbybiRcRW5YuYJ5A8HUA0qhJ3+/Nptzg+oJHw==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org;\n dkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=OX2L1x4x; dkim-atps=neutral;\n spf=pass (client-ip=2600:3c0a:e001:78e:0:1991:8:25;\n helo=sea.source.kernel.org; envelope-from=ljs@kernel.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777655379;\n\tbh=aCKpiD8Crlk0uEQZs9vyjBCgLqxVn32/cxl6Y0AtRGE=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=OX2L1x4xFIxbScfPDUbir6mmS+xdX9NmUYzJR0EJkE7ri86qbaeUTkDb4jWI5oeb+\n\t aN4JbRR+N5UIrCNNa22w2pCZ2JSMSHoSZwNy2T2qFiVEenmDxH9tkupv+ZDyGU2ObI\n\t 654hr8gYpcXDtcmeRIPh1KdMIPoWk95vpdUy3GSPXi4IHKF8A7wxn55TDFMfm9T3X7\n\t 2RVfuwK5n/jkaekIr44u2S02mSaPb7gcycVdlcOtlmx86ngcN1rcmImzOHzRA44jyl\n\t l2G+a79TnBeaUy0DKnFo0u2dmfaqSvsLz/R2tzsXHpnuJk6XOz3vggn1h43+SNrKA+\n\t 0+Ne8WhoVmpcw==","Date":"Fri, 1 May 2026 18:09:30 +0100","From":"Lorenzo Stoakes <ljs@kernel.org>","To":"Matthew Wilcox <willy@infradead.org>","Cc":"\"Barry Song (Xiaomi)\" <baohua@kernel.org>, akpm@linux-foundation.org,\n\tlinux-mm@kvack.org, david@kernel.org, liam@infradead.org, vbabka@kernel.org,\n\trppt@kernel.org, surenb@google.com, mhocko@suse.com, jack@suse.cz,\n\tpfalcato@suse.de, wanglian@kylinos.cn, chentao@kylinos.cn,\n lianux.mm@gmail.com,\n\tkunwu.chan@gmail.com, liyangouwen1@oppo.com, chrisl@kernel.org,\n kasong@tencent.com,\n\tshikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com,\n youngjun.park@lge.com,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n loongarch@lists.linux.dev,\n\tlinuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,\n linux-s390@vger.kernel.org","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","Message-ID":"<afTeKp90wGNixIOX@lucifer>","References":"<20260430040427.4672-1-baohua@kernel.org>\n <afNM-gIqxpyJ6ro7@casper.infradead.org>\n <afTKsSj0i-ZkRZN5@lucifer>\n <afTPamwDbtY_tgk_@casper.infradead.org>","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<afTPamwDbtY_tgk_@casper.infradead.org>","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3685194,"web_url":"http://patchwork.ozlabs.org/comment/3685194/","msgid":"<CAGsJ_4wk=SDtgin+84Ev2TamU-JFfmrg_SUay=-tcYmnFvK6Nw@mail.gmail.com>","date":"2026-05-01T17:44:34","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":48512,"url":"http://patchwork.ozlabs.org/api/people/48512/","name":"Barry Song","email":"baohua@kernel.org"},"content":"On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:\n>\n> On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:\n> > 1. There is no deterministic latency for I/O completion. It depends on\n> > both the hardware and the software stack (bio/request queues and the\n> > block scheduler). Sometimes the latency is short; at other times it can\n> > be quite long. In such cases, a high-priority thread performing operations\n> > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait\n> > for an unpredictable amount of time.\n>\n> But does that actually happen?  I find it hard to believe that thread A\n> unmaps a VMA while thread B is in the middle of taking a page fault in\n> that same VMA.  mprotect() and madvise() are more likely to happen, but\n> it still seems really unlikely to me.\n\nIt doesn’t have to involve unmapping or applying mprotect to\nthe entire VMA—just a portion of it is sufficient.\n\nBTW, the chain can propagate: a page fault occurs, B wants to write this\nVMA, and C (a higher-priority task) wants to write another VMA. D may need\nto iterate VMAs under mmap_lock, so B can end up blocking both C and D.","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20372-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=cokKUJ4c;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=112.213.38.117; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20372-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=\"2600:3c0a:e001:78e:0:1991:8:25\"","lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=cokKUJ4c;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org\n (client-ip=2600:3c0a:e001:78e:0:1991:8:25; helo=sea.source.kernel.org;\n envelope-from=baohua@kernel.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6dj12qYwz1xqf\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 02 May 2026 03:44:52 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g6dhy4clfz2y8d;\n\tSat, 02 May 2026 03:44:50 +1000 (AEST)","from sea.source.kernel.org (sea.source.kernel.org\n [IPv6:2600:3c0a:e001:78e:0:1991:8:25])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g6dhx3N6gz2xWY\n\tfor <linuxppc-dev@lists.ozlabs.org>; Sat, 02 May 2026 03:44:49 +1000 (AEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby sea.source.kernel.org (Postfix) with ESMTP id 569D244374\n\tfor <linuxppc-dev@lists.ozlabs.org>; Fri,  1 May 2026 17:44:47 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 0E965C2BCF7\n\tfor <linuxppc-dev@lists.ozlabs.org>; Fri,  1 May 2026 17:44:47 +0000 (UTC)","by mail-qv1-f47.google.com with SMTP id\n 6a1803df08f44-8a151012558so23995426d6.3\n        for <linuxppc-dev@lists.ozlabs.org>;\n Fri, 01 May 2026 10:44:46 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777657490;\n\tcv=none;\n b=nNpBCc2uFOKvT4/EVA16/E4HItN3pY3bmE2Rbdfl8xIZXHjhy/MNppoybycQiVDUtewxx/34jDvccbi/g43Ca7r9hVi6i6tmx2Wj7MrqA4cLUMGZNY4mPz2n8K9cHxar40jSVZTAWwafd/KEBdIIg+tHp/pUvCtgcZPqN/bVKa2eKwpN+nAoGIMovYGeL/T1Tw/64OHJIgVFF5UFPU9tmsZhuqeaCYZau5D/nxTgH3ITKposO5n3fSOgj6zTQncWDoDbetMLRiOXIedOVVTPT6bQYqp7Ig85G0S5xJtBuvkWSaiS5DFlr02Ah9XPC6W9gyDYHM/ePcrHMKRgoWextQ==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777657490; c=relaxed/relaxed;\n\tbh=9YAd4wJdBuwvuhq3A/51ZtTu6jgeC0RYN/Swb2V6zYA=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=gxIAKU0EANGJHuWrWimIYFOFZ/eq16eMIW1Q37jOnM6Xn9ifKsRvF1YbObCPRqeQlTL1XR4YIkT/PPKAUKSeHCB2Wmfzpkczs/J8jeZiuuThZ1/ss6jjZaUhiShFcBxi6rOdS7Q2KsbLh73FstxFX2Yy9oGSlBSHjRRmZM8mPlaCXYMBFca4TUwv2ZAl6Ln3HBSHLrUda1oSpwrx2SQbrE62/1DiTfMGaYXozmX4i2I1s4W7Flelzsobu30xADc2v71tFN2BEPCxb/jgKu1lbQA0RU917WjlptPv/aNwsANd92IStRc/QNR55hi+tYhqvCAQ8iDXckb55xTsnHG5Qg==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org;\n dkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=cokKUJ4c; dkim-atps=neutral;\n spf=pass (client-ip=2600:3c0a:e001:78e:0:1991:8:25;\n helo=sea.source.kernel.org; envelope-from=baohua@kernel.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777657487;\n\tbh=Hl2YiWTcbo74Gxc6IpUU70j+aHuYqyHn+c9GqocmPS0=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=cokKUJ4cVjTc6Fh+umuWaKXjfGu696YYSrhlsdu275noHQdipmmX0gkSiihTIc2Sl\n\t fpYV1mlggK7Yc6cXYI+XurdET3PGISSUYmW2rPT5S58wxIfAaO5cGneYrdxbKBfIlB\n\t XZEkY0bHXwj5IHxfWfRQxZg9bVbm6Czf+haANPTe/D+0YAlQo7B5g+S/t38bZMqyZA\n\t Hvwafr5cJ0ewDjxPrc13qWWQ0oTeI8rTw7+kBgHhpYucb3owFD/0kIrKesBp3DFJve\n\t SXoo+/ZlI3WZftzrouDPSabfXV4IkYxfnkLGV13yzz1iWbpLIbSY4Ytn/c7yT/Hw0B\n\t 9r576Ai8d9MRA==","X-Forwarded-Encrypted":"i=1;\n AFNElJ8QXMDZ4r0Jd1GWl6BLPSrW/6XG6OzR4wnVnNT35/k7c7b2Xqn0TPDq7a6kLjDeU2Rqbe+RDR6UMDXuxSw=@lists.ozlabs.org","X-Gm-Message-State":"AOJu0YwmghyRksBY19CcfUMXSPDjfHyq4+EOg09JXnyB5/gf4RoE+eEs\n\tc/xr0fNiFHnRhBv2TSEYCUvIfBsJfZ/IneFXvZB+27FOh69LiNBL8MzzPmHSwdbBRrYczTVI5lZ\n\tyCjaLKc7jFQ2+C2qY0itw7PcweJ+0kxE=","X-Received":"by 2002:a05:6214:260a:b0:8ab:4ab9:bb50 with SMTP id\n 6a1803df08f44-8b668638bfamr8385726d6.37.1777657486245; Fri, 01 May 2026\n 10:44:46 -0700 (PDT)","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","References":"<20260430040427.4672-1-baohua@kernel.org>\n <afNM-gIqxpyJ6ro7@casper.infradead.org>\n <CAGsJ_4w0qcYmukHqsyRd0jomoyYkJjOt8b-Cgp53BgP-8QQghw@mail.gmail.com>\n <afS_L-5XeWIldTXA@casper.infradead.org>","In-Reply-To":"<afS_L-5XeWIldTXA@casper.infradead.org>","From":"Barry Song <baohua@kernel.org>","Date":"Sat, 2 May 2026 01:44:34 +0800","X-Gmail-Original-Message-ID":"\n <CAGsJ_4wk=SDtgin+84Ev2TamU-JFfmrg_SUay=-tcYmnFvK6Nw@mail.gmail.com>","X-Gm-Features":"AVHnY4L9r5jHmXxuaat24ga_fMfUkn2-2M0MEFhZDB6ITf6AdiWvpvcS2QZoKTw","Message-ID":"\n <CAGsJ_4wk=SDtgin+84Ev2TamU-JFfmrg_SUay=-tcYmnFvK6Nw@mail.gmail.com>","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","To":"Matthew Wilcox <willy@infradead.org>","Cc":"akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org,\n\tljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org,\n\tsurenb@google.com, mhocko@suse.com, jack@suse.cz, pfalcato@suse.de,\n\twanglian@kylinos.cn, chentao@kylinos.cn, lianux.mm@gmail.com,\n\tkunwu.chan@gmail.com, liyangouwen1@oppo.com, chrisl@kernel.org,\n\tkasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com,\n\tbhe@redhat.com, youngjun.park@lge.com, linux-arm-kernel@lists.infradead.org,\n\tlinux-kernel@vger.kernel.org, loongarch@lists.linux.dev,\n\tlinuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,\n\tlinux-s390@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3685196,"web_url":"http://patchwork.ozlabs.org/comment/3685196/","msgid":"<afTpoL3FklpQZNMM@casper.infradead.org>","date":"2026-05-01T17:57:52","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":70855,"url":"http://patchwork.ozlabs.org/api/people/70855/","name":"Matthew Wilcox","email":"willy@infradead.org"},"content":"On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:\n> On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:\n> >\n> > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:\n> > > 1. There is no deterministic latency for I/O completion. It depends on\n> > > both the hardware and the software stack (bio/request queues and the\n> > > block scheduler). Sometimes the latency is short; at other times it can\n> > > be quite long. In such cases, a high-priority thread performing operations\n> > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait\n> > > for an unpredictable amount of time.\n> >\n> > But does that actually happen?  I find it hard to believe that thread A\n> > unmaps a VMA while thread B is in the middle of taking a page fault in\n> > that same VMA.  mprotect() and madvise() are more likely to happen, but\n> > it still seems really unlikely to me.\n> \n> It doesn’t have to involve unmapping or applying mprotect to\n> the entire VMA—just a portion of it is sufficient.\n\nYes, but that still fails to answer \"does this actually happen\".  How much\nperformance is all this complexity in the page fault handler buying us?\nIf you don't answer this question, I'm just going to go in and rip it\nall out.\n\n> BTW, the chain can propagate: a page fault occurs, B wants to write this\n> VMA, and C (a higher-priority task) wants to write another VMA. D may need\n> to iterate VMAs under mmap_lock, so B can end up blocking both C and D.\n\nI know.","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20373-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=cS0FYwD2;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20373-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=\"2001:8b0:10b:1236::1\"","lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=cS0FYwD2;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=infradead.org\n (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org;\n envelope-from=willy@infradead.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6f0W6QqGz1xqf\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 02 May 2026 03:58:19 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g6f0W18jrz2y8d;\n\tSat, 02 May 2026 03:58:19 +1000 (AEST)","from casper.infradead.org (casper.infradead.org\n [IPv6:2001:8b0:10b:1236::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g6f0S5WtPz2xWY\n\tfor <linuxppc-dev@lists.ozlabs.org>; Sat, 02 May 2026 03:58:14 +1000 (AEST)","from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red\n Hat Linux))\n\tid 1wIs7c-000000098SG-2Rmh;\n\tFri, 01 May 2026 17:57:52 +0000"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777658298;\n\tcv=none;\n b=isFS68oKANq6BNxBVFTSnnGjgRNkPfPnJudAZzrCtzyeCKSl/TX61ToDvGyE0TRUudrR5qEr7mdxJli7Ny3MlWdfDJ9Vt3JhecEx10anNV8rVAIEUr88L2RpG4fjlNsOUPWwY2HWm3yukhksb//WaDs1x0wyZubazJUalU9vqHoUTq/iA9WfFHvkBzJdJK8lrf5f+pHVn7d2OEpzFxIJKQ53ytM4vmrVKG+u3vHuzDOSveLzPAE+wcHRf33SjfSpXkYh/eg76dN4vwLv6hchlq/8rNIc61qQtV8c4qCUx2boY+Eq+MIs2f2cCyvs3cuCToqcojfS11onKty/TLDm2A==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777658298; c=relaxed/relaxed;\n\tbh=u/+O11I2l5uEWQtHiF9iLIDtrtif7F+7W2x9HgtS2Zk=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=GCUAbMijguwP8h1wFEf8j7GUAU7DP44Y7n56UvQz08eaxPAobhsNRupIm/3Mxx93qgi6puc92bL1S4ncPRVd5CIrZC36MlOqeb5QjHlMdohIl9v0Z2rMQxBKpr7lkQcgzOOPSr6EAmIZjLTzXLl8TH9tEw3ms0zjaa5TxvjIp676GGa75SRcVYXISDlDGPaWskpcsDlOdU4NFIf9qvZQ6s8EXP4cNl0wp2MgUBkc7Q6QYJefGZloQEVRqrsV8JOPj5uv67hN5kbLIROklsG2VFRKN2TNTp2n9ImeBK19fW0haagGL9RrV6eKMZF96Iogz4pVl0MdkD/m1oFBKS6uMA==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n dkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=cS0FYwD2; dkim-atps=neutral;\n spf=none (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org;\n envelope-from=willy@infradead.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=infradead.org","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding:\n\tContent-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:\n\tSender:Reply-To:Content-ID:Content-Description;\n\tbh=u/+O11I2l5uEWQtHiF9iLIDtrtif7F+7W2x9HgtS2Zk=; b=cS0FYwD2XOEYVbuKnpFKh9ZiSM\n\t0EwDyUhzf4L/Z7u5RfwH9F/lLM1NhuqZPIwTkUmNl1PS4VMevXWN1PepuvnRy9E8BXEEBe1NqpbST\n\tJCuDyJciLjPMlOgK/msGkQ/Etm/ww5vna/xrv//xWjQSuG3YKtTWGFNZVR8+M3tsp34wr0aQKFWkJ\n\tuFsTeHHXdKUGothOh1mQqNx0qA+TQ+SY8myKKpSqt0cEDRnA3Sr7IVPyxsjySvvgY2FjAsXzlkA0p\n\tPsB/KjAACHCD+NoUMzQlqunyAml2flv3i9OPzaSZZMasw49lDXCUAuGtnBBvR4d+htLsXvVM7+CgM\n\t/hohbFOw==;","Date":"Fri, 1 May 2026 18:57:52 +0100","From":"Matthew Wilcox <willy@infradead.org>","To":"Barry Song <baohua@kernel.org>","Cc":"akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org,\n\tljs@kernel.org, liam@infradead.org, vbabka@kernel.org,\n\trppt@kernel.org, surenb@google.com, mhocko@suse.com, jack@suse.cz,\n\tpfalcato@suse.de, wanglian@kylinos.cn, chentao@kylinos.cn,\n\tlianux.mm@gmail.com, kunwu.chan@gmail.com, liyangouwen1@oppo.com,\n\tchrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com,\n\tnphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tloongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,\n\tlinux-riscv@lists.infradead.org, linux-s390@vger.kernel.org","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","Message-ID":"<afTpoL3FklpQZNMM@casper.infradead.org>","References":"<20260430040427.4672-1-baohua@kernel.org>\n <afNM-gIqxpyJ6ro7@casper.infradead.org>\n <CAGsJ_4w0qcYmukHqsyRd0jomoyYkJjOt8b-Cgp53BgP-8QQghw@mail.gmail.com>\n <afS_L-5XeWIldTXA@casper.infradead.org>\n <CAGsJ_4wk=SDtgin+84Ev2TamU-JFfmrg_SUay=-tcYmnFvK6Nw@mail.gmail.com>","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"\n <CAGsJ_4wk=SDtgin+84Ev2TamU-JFfmrg_SUay=-tcYmnFvK6Nw@mail.gmail.com>","X-Spam-Status":"No, score=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3685197,"web_url":"http://patchwork.ozlabs.org/comment/3685197/","msgid":"<CAGsJ_4w4jyQTzvPSzGtv1r5G35kARHrf4WgDvEiOAw8k5AAABg@mail.gmail.com>","date":"2026-05-01T17:59:13","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":48512,"url":"http://patchwork.ozlabs.org/api/people/48512/","name":"Barry Song","email":"baohua@kernel.org"},"content":"On Fri, May 1, 2026 at 11:52 PM Lorenzo Stoakes <ljs@kernel.org> wrote:\n>\n> On Thu, Apr 30, 2026 at 01:37:14PM +0100, Matthew Wilcox wrote:\n> > On Thu, Apr 30, 2026 at 12:04:22PM +0800, Barry Song (Xiaomi) wrote:\n> > > (1) If we need to wait for I/O completion, we still drop the per-VMA lock, as\n> > > current page fault handling already does. Holding it for too long may introduce\n> > > various priority inversion issues on mobile devices. After I/O completes, we\n> > > retry the page fault with the per-VMA lock, rather than falling back to\n> > > mmap_lock.\n> >\n> > You're going to have to do better than that.  You know I hate the\n> > additional complexity you're adding.  You need to explain why my idea of\n> > ripping out all the complexity now that we have per-VMA locks doesn't\n> > work.\n>\n> After a brief eyeball I share Matthew's assessment, I really don't like this\n> series, it's piling on complexity for what seem like niche cases.\n\nI’d really appreciate it if you could point out the specific parts you\ndislike, rather than the whole series—I don’t think that’s a fair\nassessment.\n\nI’m not sure what you mean by “niche cases.” Do you mean avoiding taking\nmmap_lock for major page faults, or releasing the per-VMA lock and retrying\nthe page fault?\n\nRight now, major page faults always fall back to mmap_lock, which is a\nsignificant source of lock contention. I assume we agree that this fallback\nshould be eliminated. Or is there still no agreement on this point either?\n\nWhere we may differ is whether to hold the per-VMA lock and\navoid retrying the page fault, or to rely on retrying the\nfault while using the per-VMA lock (with the current\nmainline approach using mmap_lock instead) ?\n\n>\n> We already have enough weirdness in fault code honestly.\n>\n> Let's maybe discuss at LSF if you're attending?\n\nSure :-)\n\n>\n> I will try to have a more thorough look through when I get a chance.\n\nThank you, much appreciated.\n\nBest Regards\nBarry","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20374-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=JbTv8Nf1;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20374-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=172.234.252.31","lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=JbTv8Nf1;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org\n (client-ip=172.234.252.31; helo=sea.source.kernel.org;\n envelope-from=baohua@kernel.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6f1r34jJz1xqf\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 02 May 2026 03:59:28 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g6f1r1wZzz30P3;\n\tSat, 02 May 2026 03:59:28 +1000 (AEST)","from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g6f1q2tt9z30Lw\n\tfor <linuxppc-dev@lists.ozlabs.org>; Sat, 02 May 2026 03:59:27 +1000 (AEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby sea.source.kernel.org (Postfix) with ESMTP id B6B7444548\n\tfor <linuxppc-dev@lists.ozlabs.org>; Fri,  1 May 2026 17:59:25 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 9B615C2BCFA\n\tfor <linuxppc-dev@lists.ozlabs.org>; Fri,  1 May 2026 17:59:25 +0000 (UTC)","by mail-qv1-f51.google.com with SMTP id\n 6a1803df08f44-8b1f2b7f1bcso29857736d6.1\n        for <linuxppc-dev@lists.ozlabs.org>;\n Fri, 01 May 2026 10:59:25 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777658368;\n\tcv=none;\n b=S0ru4zNgVKGp/CicfQue6cwqupfl/1HHNR3tSefApcrviVo53Gdz+MYekMsDfkETUL/3/7nOjEpVbqqTcfHplUZD8VU04+GOIx7VLEH0atRa4HluWdTRpPZQgXjAcvFcWfN81jcjmDckJqVWOUmU39/j8Ow58cS97fp6+BMY4Mxf/eGccYE8PLx+jDkQDu88sYeh6wZhR/U6J6NT2o1jaCzx8t3krTjLpe3fZ2SPIz5pDf00piksr7P0Uz2JSc6xIT8+VheaEjtYh+OpJyHw/c6dUX02DvLQVVnaR4I3lwLozu9o0RqUAbVzhLR/v4/aEh5aT42L2S36kBPEXWyyXA==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777658368; c=relaxed/relaxed;\n\tbh=5+/e7dJt2MU31Z+SqBYGMwjuUbd0OotWBmXxOfFOWyI=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=Qs8zzeDT7z/UjvDAKeh0tvckCgfEKOcR9DKmp7oirmijf45ZZrwui9TXajkIpE62ZnCt3DFPgVVAJoa+omCMJobxJGFXAVNAc2qhTUA1Acqlu5oHMWTcvdA0LiCMaHMrJTmrYHzebpLtVVH/c+6TtLjaOVAW/X8QiSESAnLEWsScQdW6pxjeoIz3PNMs9yJoPfRgglt+i6Rk2GftuQrdh3AUIO1Ij4KDS/TJKbVbzFnPvo1tlC+F19o10ydaYf//cKOseF6PJqJ5He+2GRnbM/5lf9kKevFSkblBL/9c/W0lQ2/bNQRSN/Ls2Nnbq2iEsxxDvXiLtnQ+fbhQuRwazw==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org;\n dkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=JbTv8Nf1; dkim-atps=neutral;\n spf=pass (client-ip=172.234.252.31; helo=sea.source.kernel.org;\n envelope-from=baohua@kernel.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777658365;\n\tbh=q/vvVmaTofrvdifxLcOjX8owb4zQpccO2C7Xr55syLA=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=JbTv8Nf1y3JWuLvIXZgUs1p4s5+B1GUlld0WRZbXF6rHJnF7FXG1rC3Vd4wOH+FWf\n\t /lu8+oad1AE755FSug1ZcbNt0IQc1USHsGef5ccGfcxzq95KtuLoC1nLMlrSQKzgi+\n\t tTiQMMhrfbld8ymAgyQwEiY7I8BtqZz3pZGkD9sFmJ46nTjfdLk01RnECNuTHbUx0N\n\t /o9MUrK9GRGCK4V7AJo9DxsUNN94FU6bSe/lBLB3HEZbgoDtdPCtJ4BLITTZoIcrFs\n\t HYAyPtyGq9f56cLDbdFj9zzu20514g+BkK1RgtuqirVOywKHAzhsojpDQjUdjBms4R\n\t 0K/BQ+D5iTcCQ==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/OzhU+laW91dWXOMXfSkbjKgwoPiyEE2OdYXIIGC5Q15yv4jB1xZoYI6420ZbD6tih4JQu6lnl0KgYkrA=@lists.ozlabs.org","X-Gm-Message-State":"AOJu0YwSFyAFXRvcWIitSoDVAmm7H+yw/aOxlt9Kq5O6XKdEBrNa/YTz\n\tb4hKwtfmfNPgO8WdMK91qTGMtk5ymkoDEAnPZdwbnujMx6rlvcfI92yemPn4WJHMBsBpL3NiyYC\n\tnysGihKMRIJWq49kecTKmWBHP3zExTg4=","X-Received":"by 2002:a05:6214:3113:b0:89c:7bf8:c564 with SMTP id\n 6a1803df08f44-8b4000bc68amr106932516d6.27.1777658364833; Fri, 01 May 2026\n 10:59:24 -0700 (PDT)","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","References":"<20260430040427.4672-1-baohua@kernel.org>\n <afNM-gIqxpyJ6ro7@casper.infradead.org>\n <afTKsSj0i-ZkRZN5@lucifer>","In-Reply-To":"<afTKsSj0i-ZkRZN5@lucifer>","From":"Barry Song <baohua@kernel.org>","Date":"Sat, 2 May 2026 01:59:13 +0800","X-Gmail-Original-Message-ID":"\n <CAGsJ_4w4jyQTzvPSzGtv1r5G35kARHrf4WgDvEiOAw8k5AAABg@mail.gmail.com>","X-Gm-Features":"AVHnY4IozGRsOfIFCBuTWYpA9lpafQxUB9l3oBl_1mgfquoOdt6gfYLqIWFbDj8","Message-ID":"\n <CAGsJ_4w4jyQTzvPSzGtv1r5G35kARHrf4WgDvEiOAw8k5AAABg@mail.gmail.com>","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","To":"Lorenzo Stoakes <ljs@kernel.org>","Cc":"Matthew Wilcox <willy@infradead.org>, akpm@linux-foundation.org,\n linux-mm@kvack.org,\n\tdavid@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org,\n\tsurenb@google.com, mhocko@suse.com, jack@suse.cz, pfalcato@suse.de,\n\twanglian@kylinos.cn, chentao@kylinos.cn, lianux.mm@gmail.com,\n\tkunwu.chan@gmail.com, liyangouwen1@oppo.com, chrisl@kernel.org,\n\tkasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com,\n\tbhe@redhat.com, youngjun.park@lge.com, linux-arm-kernel@lists.infradead.org,\n\tlinux-kernel@vger.kernel.org, loongarch@lists.linux.dev,\n\tlinuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,\n\tlinux-s390@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3685202,"web_url":"http://patchwork.ozlabs.org/comment/3685202/","msgid":"<CAGsJ_4x8sNtgv7Y198Gh9NSY+SE2o_JPFAxG9aWE+xXsB9vwGg@mail.gmail.com>","date":"2026-05-01T18:25:37","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":48512,"url":"http://patchwork.ozlabs.org/api/people/48512/","name":"Barry Song","email":"baohua@kernel.org"},"content":"On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:\n>\n> On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:\n> > On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:\n> > >\n> > > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:\n> > > > 1. There is no deterministic latency for I/O completion. It depends on\n> > > > both the hardware and the software stack (bio/request queues and the\n> > > > block scheduler). Sometimes the latency is short; at other times it can\n> > > > be quite long. In such cases, a high-priority thread performing operations\n> > > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait\n> > > > for an unpredictable amount of time.\n> > >\n> > > But does that actually happen?  I find it hard to believe that thread A\n> > > unmaps a VMA while thread B is in the middle of taking a page fault in\n> > > that same VMA.  mprotect() and madvise() are more likely to happen, but\n> > > it still seems really unlikely to me.\n> >\n> > It doesn’t have to involve unmapping or applying mprotect to\n> > the entire VMA—just a portion of it is sufficient.\n>\n> Yes, but that still fails to answer \"does this actually happen\".  How much\n> performance is all this complexity in the page fault handler buying us?\n> If you don't answer this question, I'm just going to go in and rip it\n> all out.\n\nI’m getting quite confused. In patch 4/5, you suggest a more\nrestrictive condition using\nif (folio_test_uptodate(folio) && !folio_test_writeback(folio))\nrather than if (folio_test_uptodate(folio)), before we decide to skip\nretrying the page fault [1].\nThat seems to suggest we should be more cautious about when we can skip\nretrying the page fault.\n\nHowever, in the cover letter, you suggest removing all retry code entirely.\nDoes this suggestion apply only to file-backed page faults?\n\n[1] https://lore.kernel.org/linux-mm/afTQl12XcXVnku9J@casper.infradead.org/\n\nBest Regards\nBarry","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20375-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=FIVeO3aI;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=112.213.38.117; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20375-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=172.234.252.31","lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=FIVeO3aI;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org\n (client-ip=172.234.252.31; helo=sea.source.kernel.org;\n envelope-from=baohua@kernel.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6fcN5qW7z1xqf\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 02 May 2026 04:25:55 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g6fcK4WMQz30M6;\n\tSat, 02 May 2026 04:25:53 +1000 (AEST)","from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g6fcJ2f1Wz2xfB\n\tfor <linuxppc-dev@lists.ozlabs.org>; Sat, 02 May 2026 04:25:52 +1000 (AEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby sea.source.kernel.org (Postfix) with ESMTP id E45F344555\n\tfor <linuxppc-dev@lists.ozlabs.org>; Fri,  1 May 2026 18:25:49 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id CB309C2BD00\n\tfor <linuxppc-dev@lists.ozlabs.org>; Fri,  1 May 2026 18:25:49 +0000 (UTC)","by mail-qt1-f177.google.com with SMTP id\n d75a77b69052e-50e97863425so20851781cf.0\n        for <linuxppc-dev@lists.ozlabs.org>;\n Fri, 01 May 2026 11:25:49 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777659953;\n\tcv=none;\n b=DOHSxVJkrxfjIyRMzWJDa18C4jeag+ojDfcIBjMoLMlqEgLuIBGl7rz0hjk+8OMXxPzvDJjJNfO6Cnvi81VlPTrWtepk6ARsWNgrWqpIQI8d9I5VtlYabF+E+DXY13/pT0uur36S6Sn4sapnDrSQaAAQQrvoThXGDs6RnLmPIs9reJMSjx2EsiPRdexC+nJTBNsBB2WJHTlucPC1i6pkx/beXF2XRkiT3aeTdgOdrz0MFudEWejLsPEFcO6YA+j33pcxuju1BO7EUoHkQhXTuf4oLszP8fQC4+SuO+5J415Iei2xExD6F0rADPPVBBc+QhyEAUUKts4PzzhJRJYbDA==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777659953; c=relaxed/relaxed;\n\tbh=D4A1t9IUPAxFiSXYXl3Z4jwgMAwfMFsg3JsxiXOyKCg=;\n\th=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:\n\t To:Cc:Content-Type;\n b=knbkbyiDquHMT9k978XFXANFDyLFNw9jmArcR0aVMKDVsNSfoshuuW1EHsIhkZDFnKY8iqKMHyL6SoKb8PmLZHla4OOZvAyrSX2AWtuhaCeMdMH8L+14QAJPfcZH5pqihcW6EIvqWIyRjn2tuv/AkYQuRbE1Ot0/0387fQ1z+fyM8jETLrC1GAUWlW+Nk6GYOKSRdX29QWxQFDNte8Ik1R8fSpCfrtrNVj4x1QRRQDuvTux6u02fC74CLxG5rFK74qoUR3KeOtlpZN7/GqZaSVVk4S7GBAu1OMKdlWeb5oct7yegh/goz1GlwTlD6YkRZl9C8HnYeplISxTU9jsl2Q==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org;\n dkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=FIVeO3aI; dkim-atps=neutral;\n spf=pass (client-ip=172.234.252.31; helo=sea.source.kernel.org;\n envelope-from=baohua@kernel.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1777659949;\n\tbh=lT/rPel9FmT35iq3NDhHuchj5jXwn6oKumOJ4dCsmXc=;\n\th=References:In-Reply-To:From:Date:Subject:To:Cc:From;\n\tb=FIVeO3aI7z+jFqDqXITJ+jWsf7lknsacv1Vzwcn4Qsr6jBLZMM2APApvdOADED8Ln\n\t tAIwXt9R3qywh7SwzohMPLV0t1vg1LPT7kOq55TgbdDGfwhWLLAjfL+brTf/OPCywN\n\t jEfUkX05+1k8ouTnvv+GA9F+JEnzTnf5Oa3U2Pt8IrB7QbY20FMPALZdtczL2ANGRj\n\t CrACi6wIjjOv4ftAgLt74Gg2ts3YaDODuAFLoaOg1uLSZtNISIx6WZBJZfcCC4lqXH\n\t 2KD3b4Y7/PA6fAAoCZuEsL9/UflhQWvEAIT7FBdFCoa8CcfRc5UKFiKNKCX0uHRqoY\n\t UbCOWCsY8mKUw==","X-Forwarded-Encrypted":"i=1;\n AFNElJ+VxHJu4Urb2DOEOYrZcdciRR65l/99361k3sthxpBVc3HQ5YyHUmMYfb80z4vbcbn7AAZvwQGO3dUam/Q=@lists.ozlabs.org","X-Gm-Message-State":"AOJu0YxxVg9UY/AT61rdvnkTkMt49R5L0cGSMxA8WdQeda8GX8c3SD9R\n\txiykhbdPHdU+AnT/LE4Pnamf9EtCYE1V4xE9cHMBLtsDTqCP2QFQNiPYrhaY5tB1Jr3bjxrt5lV\n\tLjp7ZJnNtbVct3QfcKVnfcg72HOI5M4w=","X-Received":"by 2002:ac8:7dce:0:b0:509:2455:2b53 with SMTP id\n d75a77b69052e-5104bf755a7mr5248631cf.49.1777659948730; Fri, 01 May 2026\n 11:25:48 -0700 (PDT)","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","References":"<20260430040427.4672-1-baohua@kernel.org>\n <afNM-gIqxpyJ6ro7@casper.infradead.org>\n <CAGsJ_4w0qcYmukHqsyRd0jomoyYkJjOt8b-Cgp53BgP-8QQghw@mail.gmail.com>\n <afS_L-5XeWIldTXA@casper.infradead.org>\n <CAGsJ_4wk=SDtgin+84Ev2TamU-JFfmrg_SUay=-tcYmnFvK6Nw@mail.gmail.com>\n <afTpoL3FklpQZNMM@casper.infradead.org>","In-Reply-To":"<afTpoL3FklpQZNMM@casper.infradead.org>","From":"Barry Song <baohua@kernel.org>","Date":"Sat, 2 May 2026 02:25:37 +0800","X-Gmail-Original-Message-ID":"\n <CAGsJ_4x8sNtgv7Y198Gh9NSY+SE2o_JPFAxG9aWE+xXsB9vwGg@mail.gmail.com>","X-Gm-Features":"AVHnY4Jc3ag1bUQ2844h_SA5sVSne-TN_r5pli71-jMQXFzkdxM1Ig0IdK36GUU","Message-ID":"\n <CAGsJ_4x8sNtgv7Y198Gh9NSY+SE2o_JPFAxG9aWE+xXsB9vwGg@mail.gmail.com>","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","To":"Matthew Wilcox <willy@infradead.org>","Cc":"akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org,\n\tljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org,\n\tsurenb@google.com, mhocko@suse.com, jack@suse.cz, pfalcato@suse.de,\n\twanglian@kylinos.cn, chentao@kylinos.cn, lianux.mm@gmail.com,\n\tkunwu.chan@gmail.com, liyangouwen1@oppo.com, chrisl@kernel.org,\n\tkasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com,\n\tbhe@redhat.com, youngjun.park@lge.com, linux-arm-kernel@lists.infradead.org,\n\tlinux-kernel@vger.kernel.org, loongarch@lists.linux.dev,\n\tlinuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,\n\tlinux-s390@vger.kernel.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3685215,"web_url":"http://patchwork.ozlabs.org/comment/3685215/","msgid":"<afUBXnPVnt7Jt5hh@casper.infradead.org>","date":"2026-05-01T19:39:10","subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","submitter":{"id":70855,"url":"http://patchwork.ozlabs.org/api/people/70855/","name":"Matthew Wilcox","email":"willy@infradead.org"},"content":"On Sat, May 02, 2026 at 02:25:37AM +0800, Barry Song wrote:\n> On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:\n> > Yes, but that still fails to answer \"does this actually happen\".  How much\n> > performance is all this complexity in the page fault handler buying us?\n> > If you don't answer this question, I'm just going to go in and rip it\n> > all out.\n> \n> I’m getting quite confused. In patch 4/5, you suggest a more\n> restrictive condition using\n> if (folio_test_uptodate(folio) && !folio_test_writeback(folio))\n> rather than if (folio_test_uptodate(folio)), before we decide to skip\n> retrying the page fault [1].\n> That seems to suggest we should be more cautious about when we can skip\n> retrying the page fault.\n> \n> However, in the cover letter, you suggest removing all retry code entirely.\n> Does this suggestion apply only to file-backed page faults?\n\nI'm making sure that if Andrew decides to override me he at least sees\nthat there are other problems with this patchset beyond \"I don't like\nthe additional complexity\".\n\nAnd maybe we decide to do the fallback for anon-mm but not file memory.\nOr maybe it's just something somebody happens upon when reading the\nmailing list (or more likely it's just grist for an AI).","headers":{"Return-Path":"\n <linuxppc-dev+bounces-20376-incoming=patchwork.ozlabs.org@lists.ozlabs.org>","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=uHjHrPPD;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20376-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=\"2001:8b0:10b:1236::1\"","lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=uHjHrPPD;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=none (no SPF record) smtp.mailfrom=infradead.org\n (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org;\n envelope-from=willy@infradead.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g6hFT3r34z1xvV\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 02 May 2026 05:39:41 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g6hFS5d8lz2xnZ;\n\tSat, 02 May 2026 05:39:40 +1000 (AEST)","from casper.infradead.org (casper.infradead.org\n [IPv6:2001:8b0:10b:1236::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g6hFQ2dx1z2xC3\n\tfor <linuxppc-dev@lists.ozlabs.org>; Sat, 02 May 2026 05:39:33 +1000 (AEST)","from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red\n Hat Linux))\n\tid 1wIthf-00000009F6Q-0jSu;\n\tFri, 01 May 2026 19:39:11 +0000"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1777664380;\n\tcv=none;\n b=Qi1v295xDa8E8K60RiF0W+JB84y+nCU21GoVVSM/18lDSgpgFiT6btcdMf/nUHUldI2QXUTRsg3+jAK57i6umXqcoxw9W2JpxltOBL0x5exouv3YaFOOSD/tq/dlar0wz8usIs5U5INDCcfj/tVOa+oK8OxvBleufo7MWb5EiXkhEYE1j9fUpwpFE0MoIUKQCOQ/eaji42CGCB+pndDpwZ61gvt+UGLQcpk0LthrxftZJOBlwfaUcBAoIvy/O8LCnCgv37BQVrMiqzx2+3M4gOWnbF5X3NCwX2XFkqaap1X8Ch6s91M1V35sHbOabxtvytHNRJSoiNHe3zmNCIYtWA==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1777664380; c=relaxed/relaxed;\n\tbh=rp8f/WeQia8QAD+YJmPABxXPXrvHyOM5hZfBchCKMDA=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=Ucc7iBDpzmXbSaQ0acMAOHtavKI+sRvHNsdPU7PfvNZb2May3pgjgI70YZJ3PLxMq9yweh2HDZjDeYqL16TgEqrmiE/0vYltX1V1kGOg2aBEd7Jil05XWZSwpEsb2BVIeRIDEDsPppO99IIo4rt07jStF/xNGSLtCU7OtGW9xTMtcjBZO5HX36TRxGYc5RaTtNjXA3KZhBi/4SRtGJiWsIkglp5dDln1985zjOqfA+qRryhCyeHloHtyD6qo5Nc7nl9cHipf/NjtcipCjxGaV1w2Zn9Ft6vG2mSnbLFjQNT2Gx2kTMVWUe8AE+wyh6lqciz56R4PfZ08n3+Q8KdmHg==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n dkim=pass (2048-bit key;\n secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=uHjHrPPD; dkim-atps=neutral;\n spf=none (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org;\n envelope-from=willy@infradead.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=infradead.org","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding:\n\tContent-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:\n\tSender:Reply-To:Content-ID:Content-Description;\n\tbh=rp8f/WeQia8QAD+YJmPABxXPXrvHyOM5hZfBchCKMDA=; b=uHjHrPPD2LeDk5mLziBh3YyqEj\n\tpfhR1tJpiKuUsooCkGqL2JZsb+D6vXBCRLBIbK0Q44xOCZOqwgtOj5wLR1q5KX9Q3NvcP0rciSd+G\n\tckgC0Zlz14TMgm+JsN7ZyOCt1Uvx4cReuGP0X3rwHMIqy2VNYPteQIn4/oeQedWAMeFvYDZOK+5J9\n\tgMu8Q18KidiWTxvlLNVjdpduJUbW8ext7a3iuodZcXYJM4buozO5xWvugDSnEUtY1AeZRzE+j32qI\n\t9Rxm90eK24xcN0FvxD+xBCl3zDGmbqcxwWSaplpXlbRREhdZ7Fj4povFbiHlxELsrOySKt4514WFP\n\t5emRWH6A==;","Date":"Fri, 1 May 2026 20:39:10 +0100","From":"Matthew Wilcox <willy@infradead.org>","To":"Barry Song <baohua@kernel.org>","Cc":"akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org,\n\tljs@kernel.org, liam@infradead.org, vbabka@kernel.org,\n\trppt@kernel.org, surenb@google.com, mhocko@suse.com, jack@suse.cz,\n\tpfalcato@suse.de, wanglian@kylinos.cn, chentao@kylinos.cn,\n\tlianux.mm@gmail.com, kunwu.chan@gmail.com, liyangouwen1@oppo.com,\n\tchrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com,\n\tnphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com,\n\tlinux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,\n\tloongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org,\n\tlinux-riscv@lists.infradead.org, linux-s390@vger.kernel.org","Subject":"Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page\n fault performance","Message-ID":"<afUBXnPVnt7Jt5hh@casper.infradead.org>","References":"<20260430040427.4672-1-baohua@kernel.org>\n <afNM-gIqxpyJ6ro7@casper.infradead.org>\n <CAGsJ_4w0qcYmukHqsyRd0jomoyYkJjOt8b-Cgp53BgP-8QQghw@mail.gmail.com>\n <afS_L-5XeWIldTXA@casper.infradead.org>\n <CAGsJ_4wk=SDtgin+84Ev2TamU-JFfmrg_SUay=-tcYmnFvK6Nw@mail.gmail.com>\n <afTpoL3FklpQZNMM@casper.infradead.org>\n <CAGsJ_4x8sNtgv7Y198Gh9NSY+SE2o_JPFAxG9aWE+xXsB9vwGg@mail.gmail.com>","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"<linuxppc-dev.lists.ozlabs.org>","List-Help":"<mailto:linuxppc-dev+help@lists.ozlabs.org>","List-Owner":"<mailto:linuxppc-dev+owner@lists.ozlabs.org>","List-Post":"<mailto:linuxppc-dev@lists.ozlabs.org>","List-Archive":"<https://lore.kernel.org/linuxppc-dev/>,\n  <https://lists.ozlabs.org/pipermail/linuxppc-dev/>","List-Subscribe":"<mailto:linuxppc-dev+subscribe@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-digest@lists.ozlabs.org>,\n  <mailto:linuxppc-dev+subscribe-nomail@lists.ozlabs.org>","List-Unsubscribe":"<mailto:linuxppc-dev+unsubscribe@lists.ozlabs.org>","Precedence":"list","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"\n <CAGsJ_4x8sNtgv7Y198Gh9NSY+SE2o_JPFAxG9aWE+xXsB9vwGg@mail.gmail.com>","X-Spam-Status":"No, score=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}}]