From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1FFCC369D5 for ; Wed, 23 Apr 2025 21:53:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 96B946B0006; Wed, 23 Apr 2025 17:53:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F4A26B0007; Wed, 23 Apr 2025 17:53:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 76F0B6B0008; Wed, 23 Apr 2025 17:53:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 57D4F6B0006 for ; Wed, 23 Apr 2025 17:53:34 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 981E31A0534 for ; Wed, 23 Apr 2025 21:53:35 +0000 (UTC) X-FDA: 83366660790.26.EED8ED9 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf08.hostedemail.com (Postfix) with ESMTP id BDBA1160006 for ; Wed, 23 Apr 2025 21:53:33 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=eHiCQiWG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745445213; a=rsa-sha256; cv=none; b=Muh/1bMo6L52We3JPnWDnH7p2Tv/kcwXmybWNifyS/88NaOUqEDbwETCNpqTSUmoOxuDLc JF3c1VCTrbkIzR9t4197GmGHwE+fi/yv2aX2gynMP4LAHWHVQ8YsBdUsqkqrNH3S4k7NW+ I8zLibgnHXLlYEpMUncpsV4sjQxtYVc= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=eHiCQiWG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745445213; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+wxOEPg2lzGGAAEWxyMxHF7QDi50JL+cgIXLanH/rmg=; b=uDKUMS/RYFwXGdW0qyzy0dxszdM0axUwqX2Aips5ixpcJ512+qSvT8M9qUiyFEKjVSczX7 pMxEghItl3ppXrj99biYcUN6x7Mlc0xZjUXOiVNWcmbcQmFoBlzWSLCn8yvUvtyQbbHGHt 49q1bolpHJdTQFqYhPM06kLxZD52B6A= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-47e9fea29easo43401cf.1 for ; Wed, 23 Apr 2025 14:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745445213; x=1746050013; darn=kvack.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=+wxOEPg2lzGGAAEWxyMxHF7QDi50JL+cgIXLanH/rmg=; b=eHiCQiWG8svVMKGZtljjWkoEx3K1p/1q0R7ydGRlbOZ1Qd3TiVSjgxENVv5P7KF7h2 kGOZKriYjiVurbDpzQh+5r2ZxMLn7OJE3rWLq7wqYxUhvTClx+ElGt1AiegYWaOAmYPJ 2Eegi9EKk3tm/R2+yz4GDyJKINBRnEIvZkf7VNDdSeUEw7e8HOBfd6m+TTRsMf5767Ll AjBbOW6+tCfUv9dqBUX+PbpagW2elcNKDPry36nJyuuXY0JV+2dOFwkOc9D6c4c1jbeK o9s4Tm+y6gQ0qS5nSfStWtJd7yGcd+ae9iqGCRPsTUWDH8A/rE49tIeCt/VZJC5GbXNu Sflw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745445213; x=1746050013; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+wxOEPg2lzGGAAEWxyMxHF7QDi50JL+cgIXLanH/rmg=; b=X9maV65y2S4b07b+Ua6ycizV+H68hbqG713q5wsZv6CgyL9GFWjK9GszF4GUS2NCkE AYPFq9BFmNuWoNBbpUw8aXShoN7etHzUh7wtrmVyByKMPZh1PfgzEzoZ4ofxlM0Jjhwx DBiTTNGJoPPpWSnq6G8mK8QPv47GtdCi9XNhEOVVrFaPHwqWINpkHnfeW0ZzFBTFNpz6 OtCiUiYyQujcQ/3coRFNBqozQpjxM/2Xv+hm65+YUB2Q08u1dfh5bTalFsDLDVe5FCCv 56NJ0SS4O2Aa/MEQSO+SoXo81srsE7jElg68S8MYwt2+iN60BrzgvH+DU/u0IjF8TRyh V0PQ== X-Forwarded-Encrypted: i=1; AJvYcCXlE6QCQF+3gjWk0/6dIsYgKeoj15ZsQLCNbmJv98Zspsar+QMn51mqzLdCZ4j2gEGJHOBlMRotBg==@kvack.org X-Gm-Message-State: AOJu0YyLW2ZV1g+sY0NCM8ssgeSehpGT+zGzJeY+hx16R9TdPp1BKeJk 0H5/r9wzA0HZugNleMahfh6MdCJCYYt61cXZeZ6ESylKwvNAB/V1jise9tNulirKvEz/LC03sC+ upiyrrZ49ej+lXnkC0XB470yQ8z08Fm0hdNQd X-Gm-Gg: ASbGncvG1wjAmjKDAgNXjuptSfJsj2CJI2ISiPPbuXflk4qgKPf6X12qZDy93xTS5Ck pc2vpuVaa9AORihQE6CHTpqg+CfAso0fsLnFTft84kb+gg1oydDdyhPzU+v6YAAQKKyIR/4WxIq aJksihUpflaygDjhBvLIcjj+ybmxEax4B/TEKptDAsqG12fpB9nYZH X-Google-Smtp-Source: AGHT+IFxKf4JMsoiImdRCM9Gv2EFQUjIOz6bkJ3ODyiXPnj15zTxtQdogrWnY80WdKRS5ErJulohCQQ1CRC+j+mpd8k= X-Received: by 2002:a05:622a:1bab:b0:476:d668:fd1c with SMTP id d75a77b69052e-47e79cbfd5emr1736981cf.2.1745445212617; Wed, 23 Apr 2025 14:53:32 -0700 (PDT) MIME-Version: 1.0 References: <20250418174959.1431962-1-surenb@google.com> <20250418174959.1431962-9-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 23 Apr 2025 14:53:20 -0700 X-Gm-Features: ATxdqUFczXuJ3MtAVzm6hOXwKgR46ihWvXXCSbcxhMDhIph3juTGEiPJwzlaPbY Message-ID: Subject: Re: [PATCH v3 8/8] mm/maps: execute PROCMAP_QUERY ioctl under RCU To: Andrii Nakryiko Cc: akpm@linux-foundation.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, david@redhat.com, vbabka@suse.cz, peterx@redhat.com, jannh@google.com, hannes@cmpxchg.org, mhocko@kernel.org, paulmck@kernel.org, shuah@kernel.org, adobriyan@gmail.com, brauner@kernel.org, josef@toxicpanda.com, yebin10@huawei.com, linux@weissschuh.net, willy@infradead.org, osalvador@suse.de, andrii@kernel.org, ryan.roberts@arm.com, christophe.leroy@csgroup.eu, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: BDBA1160006 X-Stat-Signature: d74qi3wkr5j7kq7fipzczhd3chdrj9no X-Rspam-User: X-HE-Tag: 1745445213-315482 X-HE-Meta: U2FsdGVkX19K+3qYG1YEBDXmItk3gCiGW8VBd/OgyrTtCTOSTcADQWR8CGTXxuSRe6aJS2/ZilblUYkTHpRa8F6mQWsO43yV8oSML7+8l2dFDPYSaq5r8vQGhvQvzZ3jlXUAuxoPopkytq3RU9AKDeRle57gotCFJk1fbQbP2gNuurVKlxQtDyUML3uMpN4GEfGxwYo5Eu/P+QdVWC5xUELfkemukTHgi70w/rXUn3nJV9bzr/hPsODGMDsNs+vj+oFTFjIsEXXWSwWCGq5Rg564iHlqZcoHe8t9FE1jT4nD1VrCxuwfHmL0yrrM05YYy/as2s7dQ8V0Ko+F4O1wK6NRYTbGKbQQ4zTLDu7zDy/wzLYp12rc33ADKTphfbsv/HUO7Nounclll2lPu3YmOPzxLhLa/PJjYDk1bH5I30OgarPEOwIgS/jsM29cCzStXDKFt9+7bgtcNUbjJQjhWDU+1XNHqmAm+b8wUPSSr7hDsOR70ueMxVJ/fNYBmFlcaSaW6t2M64GuRmkqZdvtPdo1WHmu0QC2uiJ7kpBLlBWoREFi0B3hgljYjuxxcEnzq9u2L6cHxtPHPEo98xzstSJZAsqSgL+BgWbky4GS/tbDL2P/VY8kse83TgvL2LHhlBnRIvLB50k5jzyEXB1Gt+Vnhkb7JyVF5lRWsBI9gMoqG+XCT1Uiqn+bG+zTfq3E4C3a02nfBDhPg/qwpsDmNCELHouPU3QLSClmg2URYn3RwsMdgVs6ozpzL+nWwu5A9NUTv6LpRdSi7mHpWpy86sMaN4JFdwjjWjGlXypKoqUJPUNbdT7r77D2D3qqpuDTZGOg3EXOhnIcQCHUxrBsH+KRxLME53PzWzFbZhxHcqGG1yPvu1fc2qYX4haJiAYvVf7G/KIX0jOA0BwJN6n9Kq0j2QqsqEEPIUhqUh4oktt0gLl7CSSbBu2iyGmAtVvsR6FNRIXkSMU4nE3OaN0 CjxZtFMy IzACxJE+FbvXhfYif0J/xuuZtBOz1kcQJZICXFe9xtc2pg45XdzILBZEBo2zPipMkhbS5Qs7jOpngg1DA+tpofjpDzDdaXnIvCxaxiwTXTU6uepIhWeRFM8jYHc/mOXi5smHm18Y6tFL2RMqms/WUyvvr2/BD429RfswxezexohfGoe9ZDmDfJb+NDbWdLCaLm+xlJerkXlhUf5r0yluhDWDT6KUNnt0tj+wyoOZLggaYrMu7bMT1yOrC8hisBV1JgrfvI3dvRKy8jG/YMMdM5KDtmYXG8pKKbI6wpkX8C1WqhfYkAR1TXW8JqfnTX87/NeesRqqgbXTfR0XUt9aDK6zrCVXxwac2cky/3kzp2ltMgUI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Apr 22, 2025 at 3:54=E2=80=AFPM Andrii Nakryiko wrote: > > On Fri, Apr 18, 2025 at 10:50=E2=80=AFAM Suren Baghdasaryan wrote: > > > > Utilize speculative vma lookup to find and snapshot a vma without > > taking mmap_lock during PROCMAP_QUERY ioctl execution. Concurrent > > address space modifications are detected and the lookup is retried. > > While we take the mmap_lock for reading during such contention, we > > do that momentarily only to record new mm_wr_seq counter. > > PROCMAP_QUERY is an even more obvious candidate for fully lockless > speculation, IMO (because it's more obvious that vma's use is > localized to do_procmap_query(), instead of being spread across > m_start/m_next and m_show as with seq_file approach). We do > rcu_read_lock(), mmap_lock_speculate_try_begin(), query for VMA (no > mmap_read_lock), use that VMA to produce (speculative) output, and > then validate that VMA or mm_struct didn't change with > mmap_lock_speculate_retry(). If it did - retry, if not - we are done. > No need for vma_copy and any gets/puts, no? Yeah, since we can simply retry, this should indeed work without trying to stabilize the vma. I'll update the code to simplify this. Thanks! > > > This change is designed to reduce mmap_lock contention and prevent > > PROCMAP_QUERY ioctl calls (often a low priority task, such as > > monitoring/data collection services) from blocking address space > > updates. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > fs/proc/task_mmu.c | 63 ++++++++++++++++++++++++++++++++++++++++------ > > 1 file changed, 55 insertions(+), 8 deletions(-) > > > > [...]