From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f43.google.com (mail-yx1-f43.google.com [74.125.224.43]) (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 A751813C9C4 for ; Wed, 8 Apr 2026 00:35:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775608524; cv=none; b=nU7wqPH45+a+MGSuWOo5sS2Q0sW/qbOMFbWe8C4b+4itRVuSjNjnD1gA6cBgZy6SEDyGXriJBMvkFzEDOKHRoy40v7JLYmaumv/b21YTDBsiTZ3xyKEyDMff3Lat+oe1eJLKIt+4bDXnxPEI75uxfoADLFPijvGLI5htdg/n4Hs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775608524; c=relaxed/simple; bh=afJuu4dlI7f2TDefTh9ZZJTZCY82BOXRGtrJ5qI5OF0=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=tJcfzxDn60PtQdQ+Ihs+PBYT/vxf4hsuYIDsS7hHqKpx6wLKzMbC3zu0GNlVm+GYvkZKOHEYSpES8kWlJEzk3r9krxdRmAM5wFmvtCft+3GWxEzgnYEnx23LlDDmDiH6M66kpiAxjtjiBMzumWcSu+0inBpYzw4PhuATdm9q+/o= ARC-Authentication-Results:i=1; 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=h6n+X0GL; arc=none smtp.client-ip=74.125.224.43 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="h6n+X0GL" Received: by mail-yx1-f43.google.com with SMTP id 956f58d0204a3-65032e9cf01so5368296d50.3 for ; Tue, 07 Apr 2026 17:35:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1775608522; x=1776213322; darn=vger.kernel.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=55E878MxgP72O9eei0qCPXOsBTcpsSSj+qhDc+Y73Ic=; b=h6n+X0GLX0nnl1AGFJe4ZGYt8vVOH/8dXp8a+G9m5KevXyoPeBWYZyfJ9HekbU7vMb D+VKhkqyPFOgerXzpapBrNmG4/Bc6ZFBXT3t5hii6BcLIleOtWE+QYZGDEgWstzIO3iE ZzuhMbfJiAGzglU+siKU1tKLZDQfxrrv+RDdPEedZw4dTSjm3Llwk8NNGDfqiDXW4pxi eQBrH/M3ZEG+Y6D7av3SIPvaN++1DiUmAGyjIHziyR2tXNiWkvBfo//Yp9iyQw7EA57H hR9uV2Cqxkkz0q4Xo2i3TCY26WbBd4fLBJ57J2YoekhJC3ecO4VS8H2MaGpU8TQ7vilH MsEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775608522; x=1776213322; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=55E878MxgP72O9eei0qCPXOsBTcpsSSj+qhDc+Y73Ic=; b=W7h8gvwZ92QUHfiDjEBWnEum8H8JIJLJ//8jZ8PlaEVw75CXU1IsT5twB2qlCI+jir hL3pXWLFnr8cLiEbFvDSTp7qrEwRudhjFkuyAHF2RZ3thECJL9kJaGhzb0ENZh156E+6 EmB/w9lAmjBIDCwV6tD3+6I85p9B4pFdjZahdo/fBUqzWlClgXko+yuhB9eDBB/0QNlF StJEG48+bBEXC75r8MsD97NGIptEGJ3tzoTURubDi4nVpR9EYZqq9MfFWjiCfmMbSGRf SNwC6YxUdWbATc/WSrfCGlaOKNHJqj8OyWyyK4JBJRvA8u0i+NvhdpheDDJDG03O6Lss Yg2w== X-Forwarded-Encrypted: i=1; AJvYcCVkCWTOza+ceRv5Xp3QAfku5SvXtTbip3JsUoW9WkCbyUZfDdkFmCh6MUdkTn7wFXDLPNEq8DfJsSoPFlg=@vger.kernel.org X-Gm-Message-State: AOJu0YybfUdIvwzzsQw8LUPXskDvi1fp3xdk8S1z76jGWYJBXqna0AwQ b4rEhxdQQczolwLAONiFWS7P9SAh5eQDlCOlOeW06SnIUZLSiYde4nc/MjesW7Xl3g== X-Gm-Gg: AeBDievSdxE+9mYsZEubUZk3K5LrCbyT8vr6Dwp2NSoJSRr8wGmPVrvjw03M4MVY30m sBHRynyeVSMqWrzJcN1rrqHFLwm8qvZ0Z1rdVXvoxulFx4dHtF6gmFIPGeotx2QFdMrtaWagn59 bxcD4vk3pmejHDX4GG4JrMu5LsPOAyvg+C1Ng2yVgLdWXpvZ2VIEZl1xMwbJHNqlIqpn3KqUXT3 pn/Q6N4KVeYCRV1Bfy0S624096ZoD4FadcyHaRjYprOOQdx9hIfxlnTzTyphGCpgGjNsGsAqni0 7acReVARZceAlWYeDdLzlKiBvMq8RHA1SbF7l6g9JCk3k5mQHRfP/R2FNj5oo2uqmypBh+jYaHl xEGUhFtxPsVzziXeg8ETZRUGdalWgfcmDSvh236nXXf+3Zn8jclYPhZrasg7u3O2XXTcvPZG0t8 nIzy7aH7xpEB+rsQD5qmQb75IDynA/+ZU3EIeu87SLASSV1W3CG5j/J9NX13COeeg0hmJK3MXrP Z8HSqFiqAQ= X-Received: by 2002:a05:690e:418c:b0:650:72b8:e7b6 with SMTP id 956f58d0204a3-65072b8e8b1mr7721195d50.0.1775608521304; Tue, 07 Apr 2026 17:35:21 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6503a9a9271sm8607789d50.15.2026.04.07.17.35.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2026 17:35:20 -0700 (PDT) Date: Tue, 7 Apr 2026 17:35:18 -0700 (PDT) From: Hugh Dickins To: John Hubbard cc: Joseph Salisbury , Andrew Morton , David Hildenbrand , Chris Li , Kairui Song , Hugh Dickins , Jason Gunthorpe , Peter Xu , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , linux-mm@kvack.org, LKML Subject: Re: [RFC] mm: stress-ng --mremap triggers severe lruvec lock contention in populate/unmap paths In-Reply-To: <4a4f5b48-8a1d-48f8-8760-0f5d43b5d483@nvidia.com> Message-ID: <982e5964-5ea6-eaf7-a11a-0692f14a6943@google.com> References: <4a4f5b48-8a1d-48f8-8760-0f5d43b5d483@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Tue, 7 Apr 2026, John Hubbard wrote: > On 4/7/26 1:09 PM, Joseph Salisbury wrote: > > Hello, > > > > I would like to ask for feedback on an MM performance issue triggered by > > stress-ng's mremap stressor: > > > > stress-ng --mremap 8192 --mremap-bytes 4K --timeout 30 --metrics-brief > > > > This was first investigated as a possible regression from 0ca0c24e3211 > > ("mm: store zero pages to be swapped out in a bitmap"), but the current > > evidence suggests that commit is mostly exposing an older problem for > > this workload rather than directly causing it. > > > > Can you try this out? (Adding Hugh to Cc.) > > From: John Hubbard > Date: Tue, 7 Apr 2026 15:33:47 -0700 > Subject: [PATCH] mm/gup: skip lru_add_drain() for non-locked populate > X-NVConfidentiality: public > Cc: John Hubbard > > populate_vma_page_range() calls lru_add_drain() unconditionally after > __get_user_pages(). With high-frequency single-page MAP_POPULATE/munmap > cycles at high thread counts, this forces a lruvec->lru_lock acquire > per page, defeating per-CPU folio_batch batching. > > The drain was added by commit ece369c7e104 ("mm/munlock: add > lru_add_drain() to fix memcg_stat_test") for VM_LOCKED populate, where > unevictable page stats must be accurate after faulting. Non-locked VMAs > have no such requirement. Skip the drain for them. > > Cc: Hugh Dickins > Signed-off-by: John Hubbard Thanks for the Cc. I'm not convinced that we should be making such a change, just to avoid the stress that an avowed stresstest is showing; but can let others debate that - and, need it be said, I have no problem with Joseph trying your patch. I tend to stand by my comment in that commit, that it's not just for VM_LOCKED: I believe it's in everyone's interest that a bulk faulting interface like populate_vma_page_range() or faultin_vma_page_range() should drain its local pagevecs at the end, to save others sometimes needing the much more expensive lru_add_drain_all(). But lru_add_drain() and lru_add_drain_all(): there's so much to be said and agonized over there They've distressed me for years, and are a hot topic for us at present. But I won't be able to contribute more on that subject, not this week. Hugh > --- > mm/gup.c | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > > diff --git a/mm/gup.c b/mm/gup.c > index 8e7dc2c6ee73..2dd5de1cb5b9 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -1816,6 +1816,7 @@ long populate_vma_page_range(struct vm_area_struct *vma, > struct mm_struct *mm = vma->vm_mm; > unsigned long nr_pages = (end - start) / PAGE_SIZE; > int local_locked = 1; > + bool need_drain; > int gup_flags; > long ret; > > @@ -1857,9 +1858,19 @@ long populate_vma_page_range(struct vm_area_struct *vma, > * We made sure addr is within a VMA, so the following will > * not result in a stack expansion that recurses back here. > */ > + /* > + * Read VM_LOCKED before __get_user_pages(), which may drop > + * mmap_lock when FOLL_UNLOCKABLE is set, after which the vma > + * must not be accessed. The read is stable: mmap_lock is held > + * for read here, so mlock() (which needs the write lock) > + * cannot change VM_LOCKED concurrently. > + */ > + need_drain = vma->vm_flags & VM_LOCKED; > + > ret = __get_user_pages(mm, start, nr_pages, gup_flags, > NULL, locked ? locked : &local_locked); > - lru_add_drain(); > + if (need_drain) > + lru_add_drain(); > return ret; > } > > > base-commit: 3036cd0d3328220a1858b1ab390be8b562774e8a > -- > 2.53.0 > > > thanks, > -- > John Hubbard