From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 358CB1A3166 for ; Sat, 20 Jun 2026 23:49:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.172 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781999351; cv=pass; b=onMtu6wD/tihx9WQ1jEIJBCA0jusdOIkyVO0Oik+JTQxgFPP3Vwx0lu0jU6ckEklMXKk1X74n6PZolgebtJUbpmDrATpwRl6AkgXBBXQrpF1q8y1SqO+cKWcgyik8qBXK9IhDtICWXo/OeiHRMp5OKL0brvlYF6G/H2TCYKZlG0= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781999351; c=relaxed/simple; bh=LVrIryE2VF1sDSS46HMWn0Px6aDg+06V1VeyZcyjwRw=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tRBt0IqFkAoAebQoCm8bj8cPAhnf6nRSOx8PH4h8l0A3TRYvCY18LDovWD03MsRhL44t4P/go5FQy1JvUzf0DP6Cw/B6vd5wDsTGU3+JEjtHreMh1WCyNY0sxLskXfN+pepEc+w49pe1fjcaBtIKpIQpM2usmfZZJxtwtizHf8M= 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=ZuhY1NrE; arc=pass smtp.client-ip=209.85.160.172 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="ZuhY1NrE" Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-519ed52bcc6so339631cf.0 for ; Sat, 20 Jun 2026 16:49:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781999349; cv=none; d=google.com; s=arc-20260327; b=RKCdfxx3L5BoDy5ZAcIwFZz+nLH1Z5K4LWEWtB7sDOt3JFnUCIAwh80JwzT/zaLDEd zEA6kw+dv8NYG7ranF0RCkDUDJD6qdFi0OP9nUC8TlFk6Dh7utC7UwImbem7zfN7Aq8b uMbh7LzLud+vZwdPj7u6wgExFoRl2th2Ec/7kDkriVxtcnssieUoJ51+/cnu2+41TfiP imQINBjm9F9jIZMYjjAXnj29l8ukQOWpraV6fgoq2IlzTjXFGR4KZL2dexNjlWoAf9WT otAvAaw37ebioOPM4lZ3ILfqhPOfd0eEOx2xUGlyt4LfKA4bvNXsehPMOd/WPpjqLOdr iP5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=LVrIryE2VF1sDSS46HMWn0Px6aDg+06V1VeyZcyjwRw=; fh=6XVxqy63wZpVY69ZZCstLf28jGKiPaKJR2E6rDI5zOI=; b=Anfg4MuzG/XjbyHkgGyzgeE9DMd/rud+zLtQzHEqxtTDq0ngP6Dbtepn8X5DMLYcCu n+/c+O2U6OeW0SCKzGUIRa7SbD0gZzdIZA1oC7ost7Apa1946u3ofMkURiOY+8pdwstr PTzw/2LE6mDWvHaED4cGgmo1C/pER5yt4CJ1CWWxzXdkopw0wGXuhhMhp0qCdw/drHKK ssYytHN4s8qpwYhM6UYH4lbf771XsOjRzouCPxHTaYP0ypx0J2aW/lG4Yk1lDy6OVPt9 o5eZRMiZi6DjFDKn17ovx6vbYbtaASIEiMQGQYs8k/kghoIppZPSyMD2AfN5j3HsUedq NDVw==; 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=1781999349; x=1782604149; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=LVrIryE2VF1sDSS46HMWn0Px6aDg+06V1VeyZcyjwRw=; b=ZuhY1NrE8ExUAIFrugMKZ3XjaKZQkEE9VEN6ET/lv/dMLPhZ5+Edrcaz3nq4zgBX3I IHQUsf1x4iRIs7afwYQH6LzfZn6lhzOiCpXFOslU1+Z3lQPy0K/gVEHE3DN7YpSgVxY4 7VFO2PsWoCbIco38oVTL4DA9Zc1dqeXssCyH36u96Abrb/DXHinJElWNE/P/AYvX7RYK tiQ4l86KNzkbXKjyMxefXkNCwPF5fcCEYu0gy+QP1xt4A8cyffd67iaUtnUdnN3dHHTf iLeJV2TcaMtOBwUqpRpJw7R0KCF2icBTpkrh9wTUpm2SNDYwUbsGYpwFeJRkjjQMjDP8 x02w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781999349; x=1782604149; h=content-transfer-encoding:content-type: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 :content-type; bh=LVrIryE2VF1sDSS46HMWn0Px6aDg+06V1VeyZcyjwRw=; b=LMCtFz6QnsagJDouqMaeYb5Rz5ERTmReqjK/kthhrikcGTcwNLrF3bpxgNWXeiYK09 gGNfmKCrXjGgw895aF670TboH+8f3cnBEAQNcLQ+nVtXhI/aEsWe2AkKkaIdjMSeSHdL EXzyK+H4nttfrj6+MzAx/LzTOraoTHZ9Ig+iAhu/cpLRVtGcVsSjmNuT4n/v7P4E7v4G fJXR0MB2xzZZJCs16uucAG86CvimaTJTpxrkzL2Z3w1ivm1vKJy7C7VuK1xbRkz4Hfya g79HiGOL9Kb2CubUQ2jZTA6X0+XbUnlA8FhHEgyGhoTfKjepAbCxP6zx/nOvN+txjVju PuBg== X-Forwarded-Encrypted: i=1; AFNElJ9eDuztyKjUQpUxk1W38r90Z7+cHiaDvpLDwVo/bDm257H1VMPfPnCvBpue4RzEUuot1mpNBOtfKmA60WU=@vger.kernel.org X-Gm-Message-State: AOJu0YwnfpVrLnFztOsY/urPduG3n99LpkIU4JATbBduVbh2a/hk/yx+ S1Kh8bIiqmsbtE9MeVdA5fTLL1taz4Ec8fZXZI/UWp32q0FIh3Dsn6L5y4NKAHdeNFwAWLwN+r6 Czxjx4icJjrYsGMvnUlkhuMDWxbtMks4g7hlSLiCS X-Gm-Gg: AfdE7cl7I1fPXjJaYmikAO37JzUqIt6K7KcbT71+Zp/yVLbKwa42B2QK23NAqIhAQdx NwFo0tcG0DPspw7Mkk83JKw3I1X2uK1FPknttWvpR83d3SaVTJ1+ThpOL0fhyBOEDEgQCEnp8tF lnhFEwTrGZ9Uz87vkEBN0+jO00ci6yBE67wXbkrvmu3XLnSkeNUlBlwbc9Z+jyWIrLg5EhQdml6 lOXDG5OhL/wr55G9Ejhbh8NT4FQO3nGA9UnZQZkj4RuucO0j9FwLpi0ss8o0fQS9QQHQrJCIbJs E1IuyQ== X-Received: by 2002:a05:622a:580a:b0:516:4f62:85f1 with SMTP id d75a77b69052e-519e4a744d4mr15890001cf.22.1781999348457; Sat, 20 Jun 2026 16:49:08 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <5zdaa5uv5oj27q3taopl3amops57ouxgyfsdveudz4ovmbdw7z@6lwrlyvmhcp2> <3be9475b-0e8a-4df8-a130-4262f993973d@kernel.org> In-Reply-To: From: Suren Baghdasaryan Date: Sat, 20 Jun 2026 16:48:57 -0700 X-Gm-Features: AVVi8CdrqLszoGfh6nxxBjM6ZU4jlgAaXlfN0swetCJNc_4l9-uU6mX0T8CUJHo Message-ID: Subject: Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance To: Barry Song Cc: Lorenzo Stoakes , "David Hildenbrand (Arm)" , Matthew Wilcox , "Liam R. Howlett" , akpm@linux-foundation.org, linux-mm@kvack.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 Fri, May 22, 2026 at 2:31=E2=80=AFPM Barry Song wrot= e: > > > > > Again this is making me want to sit outside and sip on some lemonade an= d > > ice :) > > > > Yes - android processes are aggressively multi-threaded, sure of course= . > > > > The missing bit here is the forking - what, where, why, when? > > > > I really want to know the what, where, why, and when > as well. But since most applications are not > open-source, it is basically a black hole for anyone > other than the owners of those apps. > > Let me try to do more investigation to understand what > is going on, although it is really hard. > To be honest, I would rather the Android framework > completely prohibit apps from calling fork(), if > possible. > > > And then you say zygote is sometimes multi-threaded but sometimes > > single-threaded, which is adding a whole bunch of confusion on top of a= ll > > that. > > > > I don't find these stack trace dumps all that useful (though thanks of > > course for taking the time to gather them), I think we'd be better off = with > > specific data on forking, in some _concise_ _summarised_ form, ideally = with > > numbers. > > > > There's such a thing as too much information :)) > > This trace shows PF I/O in one thread overlapping > with a fork() call in another thread. > But as I explained, I really do not know what kind of > user behavior is behind it. > > > > > Anyway, again, please let's see a new _RFC_ with the approach proposed = by > > Suren, with some _succinct_ data demonstrating _exactly_ what the probl= em > > is, so we can make some headway here. > > Okay, sure. Thanks for your patience. Just checking in on the followup plans. IIUC the RFC mentioned will try to implement the solution we discussed at LSFMM: splitting VM_FAULT_RETRY into two flags - one for retrying under per-VMA locks and another one to fallback to mmap_lock. Barry, if you need any help or clarification, please do not hesitate to contact me. Thanks, Suren. > > > > > And now I'm off for a cornetto! :) > > Sounds good :) Enjoy your cornetto! > > Best Regards > Barry