From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0794C35295C for ; Wed, 20 May 2026 05:51:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.173 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779256298; cv=pass; b=j/GvMse3T4eMGFxXKHBOtdgo5KeDmWaR7yXjB9tF47B6NPVScKPFwk04rSht3ASD3t75AtltO++RIBbsl95/p5/FkqTGQhfY9ArZDT94oi7NOIrBoFnm1TuIRmA3riLl08gBsYWQDQW6TAkTy/83qRnUoapEFolL8TbGLrKPC58= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779256298; c=relaxed/simple; bh=Gt9LoBM9h0v+gvRnQ1bJjfV7wmkEM4+ijibPUWac/Iw=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=RCfuZYf83QypCxSFUrUFx1uLThYG3Y81x06nmehecplZ38OzMRYN+YkxxHCQHRdrEoaRfTdRg1BXxaJW/Z/w3sIVZIkWdU3TZX3laAGgNlsgR3ROR1BVgsAyZ/aCIf8GcHkwmz+Or+qWWmDMvEYD+FVAuv7a2/hMkYW0BPo4KpE= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Sr3vpPW0; arc=pass smtp.client-ip=209.85.160.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Sr3vpPW0" Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-50d864c23bdso15401cf.1 for ; Tue, 19 May 2026 22:51:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1779256296; cv=none; d=google.com; s=arc-20240605; b=fvK4mH16g1UZRQxHmb1zwz9M64BRHqnyF19/eN7JUAgKzwpZTBwE1m0PBB8rl+ZerI BOwju5ggZ4xHdQ+AiJmxELpoPksNm+yB2fS/pLlvc11wG1PzmtDTQPx9SdNS334ldBgK ckC2J/bbjNM0fBHTHCu4F2upOHUwUZiTZLHo5aC5K9rpkHXA2T8epd/CejXhnIRJfgr5 XmyqhODCECwCs6pusN0MA5HyNAKYEw4+82JSEWVGIhkBoFllDdfQLAJG+D269Tm3tBLL lb05zJi63azaESDYbff+jUENv2M2UFNdplUhJ0g/9u1AiYIPZDVC/vEJyfYFRsoL6Xgm MPcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Gt9LoBM9h0v+gvRnQ1bJjfV7wmkEM4+ijibPUWac/Iw=; fh=igEHDDaokLRr6L+e0Pi4AKrnCoDHo2M7ZkndqW/3VWQ=; b=UqFBmLoteyNM7Qa7Nj8U/wvB8IkL/1STHo3f9/xa73ARR8GByg6U3U5bh6kRbE6EL4 9aGq8q1aQ+iQCscMskvgXN3fe7mQRL8m5OGBY1sPwWrDTESnRQtasbuZDzqFK0UKSTut 7GDj1bz2U9Pbvlw3PHNQnbtUETT0u39XbH3LjxckSM6bRH2e9JDcvlfYXYdrJcxYjyzI jUOk9BIhPly7xOuQqNRmlIO6o9BcVpAzk3gCy9dlepPjS0I2IFWrLzplpyKiWgBTbR5z gcPvILrO91RFFIN1HLCSAI26Jd5ia1loLtuJddC7qI0CiBcRMgEFjIiHCGRUvjxNLiSZ vFhA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1779256296; x=1779861096; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Gt9LoBM9h0v+gvRnQ1bJjfV7wmkEM4+ijibPUWac/Iw=; b=Sr3vpPW0X3En977Z3DFQRK+bnV3g9hofNYaA6Pyaux7C1VsS1B/ETM8jOTtnlIjqg9 wVdeLgtW0QPwhJqC4QuH04ngkp2egJczmKmnhbh0B91ejQrmqzPLPF7wri5E2WD+pWia Q1cZCZ1AjvQopHidN6HWmwIsdYlLsdpA5HiNcUHl/R9W92p9JN/8HRl7i0d5wQhJ/pHF M0Hsct9+insIuVCxc8EHQas3p4LTgIyAXDr/eNw5OW5GJogUa/dpkwxT82u+m3OFwFje kmZglEbuNygv0wx4OM/seQRINPlHzv1GUujLUmTyP6zZ9DfqVvaONfYhLKZkMCd5C3uw UWxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779256296; x=1779861096; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Gt9LoBM9h0v+gvRnQ1bJjfV7wmkEM4+ijibPUWac/Iw=; b=UgVdHnwRUVMb0wZ1h+ES5UFtfuZqGHPuAhQYD3cUShZCZaDzHjigqLmeBCeOV/OUhs fKD9EQb/LltYqT0NLnPmmEq8Faa5XyLRbQOL2DC+8jhGnTtoLJJJ7r38tcjwNK9Iilee PQlCgs6fGEO5Ps+01QxE33K1PU/Qex5gA4Rjx/I7BVFwEq0F6eLVQRVHvdP95inHyT69 tTye9j9S2XoWgiWYf6az9ZZuRvSloeIOAQds5z/n2vmVUl63BaRNRGwSIq0OKNetIro4 tvMkSuqA4VEitRbcR+1jEzhhOkO2vioKT6trablb7Wl7TdJIt3t3RHboIlfaLZn2Msza 4WAg== X-Forwarded-Encrypted: i=1; AFNElJ/YaGch1n3AMVyLkwmnvekfYmM8k5hONE5JEj4+TlcXzxTZMDWpLPhX9x+ED6dInYrfpC/pRmgKohD2k6U=@vger.kernel.org X-Gm-Message-State: AOJu0YzBFJRM4nYPiBCVpDN9Pdi1zcJPk1P2OQUXX281RDRCN/xBuQLE dbLBFeTf8491natFkDw0tLkRmBSFniODShP0ym1Ht51ld3LAIKuhtxnRAsaHtntD6LuEcgAWrN0 rkYgK4jkPjlp7xZDCCtMPfZ4sc1e1x1okzGjLQbG7 X-Gm-Gg: Acq92OH+nzq+J4ikkqouP2//TfIl7xm+rGDOg6CqI3AqKMGiJtHbCzSN1MVsfsFUgVl Vsm1iPjRilbaZ4RaXaWOMJeVXylMSzYXn5Lgz9KvDOk4fNdtXJRdtnSXx6AS4/rPTHGj+X6G8TC YyaeElQ1AavOjBFzVvjhIW69Y2sbdNbJtS41s1i8+oEXtOtoPQbesz2H6co553wHrt0SDY8GhnB IYkJwI189r0bhGGlVgu3hGU/YohRIf6R3kENnqwtyTjj9O0PMF4S0CD4ihTKjgN5CJ8BK1aIK4R EIysfIpQeS9+FVa9N21xsiyznLnU6tWsuUn18J4yaEvLDg== X-Received: by 2002:a05:622a:1920:b0:514:b17e:86f3 with SMTP id d75a77b69052e-51679461795mr15633081cf.12.1779256295164; Tue, 19 May 2026 22:51:35 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260430040427.4672-1-baohua@kernel.org> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 20 May 2026 05:51:23 +0000 X-Gm-Features: AVHnY4KMccW5pUeVLxDyTF9Gnh50gzRE3EOZpgiKFqqXipSU5KPE9rQdYzJrFBQ Message-ID: Subject: Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance To: Lorenzo Stoakes Cc: Barry Song , Matthew Wilcox , akpm@linux-foundation.org, linux-mm@kvack.org, david@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, mhocko@suse.com, jack@suse.cz, pfalcato@suse.de, wanglian@kylinos.cn, chentao@kylinos.cn, lianux.mm@gmail.com, kunwu.chan@gmail.com, liyangouwen1@oppo.com, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, Nanzhe Zhao Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 19, 2026 at 12:53=E2=80=AFPM Lorenzo Stoakes w= rote: > > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote: > > > > > > > I think we either need to fix `fork()`, or keep the current > > > behavior of dropping the VMA lock before performing I/O. > > > > I see. So, this problem arises from the fact that we are changing the > > pagefaults requiring I/O operation to hold VMA lock... > > And you want to lock VMA on fork only if vma_is_anonymous(vma) || > > is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for > > anonymous and COW VMAs only while holding mmap_write_lock, preventing > > any VMA modification. On the surface, that looks ok to me but I might > > be missing some corner cases. If nobody sees any obvious issues, I > > think it's worth a try. > > Not sure if you noticed but I did raise concerns ;) Sorry, I didn't realize your first comment was a conceptual objection to this approach of allowing page faults to race with the fork. > > I wonder if you've confused the fault path and fork here, as I think Barr= y has > been a little unclear on that. > > What's being suggested in this thread is to fundamentally change fork beh= aviour > so it's different from the entire history of the kernel (or - presumably = - at > least recent history :) and permit concurrent page faults to occur on a f= orking > process. > > I absolutely object to this for being pretty crazy. I mean I'm not sure w= e > really want to be simultaneously modifying page tables while invoking > copy_page_range()? No? > > OK you cover anon and MAP_PRIVATE file-backed but hang on there's > VM_COPY_ON_FORK too.. so PFN mapped, mixed map and (the accursed) UFFD W/= P as > well as possibly-guard region containing VMAs now can have page tables ra= ced. Ugh, yeah, I realize now this is a minefield. Resolving all possible races there would not be trivial and might introduce other performance issues. > > That's not to mention anything else that relies on serialisation here (th= is > would be changing how forking has been done in general) that we may or ma= y not > know about. > > The risk level is high, for what amounts to a hack to work around the fau= lt > issue. > > I suggest that if we have a problem with the fault path, let's look at th= e fault > path :) > > So yeah I'm very opposed to this unless I'm somehow horribly mistaken her= e or a > very convincing argument is made. So, current approach of dropping locks during I/O sounds like still the best solution. > > > > > > > > > > > > > > > > > > > > > I'd also like to get Suren's input, however. > > > > > > Yes. of course. > > > > > > > > > > > Thanks, Lorenzo > > > > > > Best Regards > > > Barry > > Cheers, Lorenzo