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 C2549C38145 for ; Fri, 2 Sep 2022 14:46:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF3FA8D0025; Fri, 2 Sep 2022 10:46:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DA3998D001B; Fri, 2 Sep 2022 10:46:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6B838D0025; Fri, 2 Sep 2022 10:46:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B8C988D001B for ; Fri, 2 Sep 2022 10:46:05 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 6A4F01A112A for ; Fri, 2 Sep 2022 14:46:05 +0000 (UTC) X-FDA: 79867420290.07.2BF5286 Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf30.hostedemail.com (Postfix) with ESMTP id 070798007E for ; Fri, 2 Sep 2022 14:46:04 +0000 (UTC) Received: by mail-yb1-f173.google.com with SMTP id 193so3401975ybc.10 for ; Fri, 02 Sep 2022 07:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=LfUeyyDPya+VM647W1kMLyuQpfGce9UnDrfOM4ed8c4=; b=e0bgvUNt2OZOKlrz9Uhod/iPoeq/YHNuYYxXRXzkQZFnKZJPbP3w1MiVETfphi+oUY NnwADo8XUIa6iAJsnICK8/X5V0B2AIOUpZn+MxVC07Mg7fTnk+KN3Nxg2k89JrTfLEoS P/i4zedRfe8ZHQESbWl2MbNru29hysWZ55bDSzQd9ATfo5lCkmG7w/2WN+8quIl3Tc6+ ufdw88gWTnF/DyhiJsMEssR4BHxjWxCuTR5kjhtXGyT2FS4PXA4k3J+wIOTZc1s/8KeS 9CY0GPFl0aws7Gzo/0AfaSxU831snBW0fT23aqWB8RaAGN5QRaQdpwT3XXuFLQu2tIPI GT+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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; bh=LfUeyyDPya+VM647W1kMLyuQpfGce9UnDrfOM4ed8c4=; b=7m3+VkvhIMAN5LJ9d8a5Gy/jXfQC4Q+4E37gxQ8cfOj/ARy+yjwHZc4KR4FauzcT3D t/aCHnNYngrETwPeF8EPNotx3ITfzO7dvDkfEwXv4e6w2jfq9rDJqrM9+oJYZJ6uHEQ6 ImzC//+Q36zFNE6VArD21vG+ycIMtrRaGgkRmplt+epi9tyCRfQdC17ESHLTt6ncT0JE 1rHO/Ap9oOX7NVRzrWA7DltxwF+ps4wkMqDSuRixRNX6zeN86riilnvSZH/iG8f2c/zC HpdTrwg74OnTB89LN3/31GNDJzSCQY/bVxdM5WJVpfB1c0u82xHpEhD1SiogA7bMKTtv llug== X-Gm-Message-State: ACgBeo01ee+CvvgHPiNZZ6SLaRCpS095inL5A1Zpjci0H3V8/y1SkkEE k5+ACmZPL8M/bTuLzCqQ/N0yp16kkVSs7fszaWLGpw== X-Google-Smtp-Source: AA6agR7KJcXL2ZM2hJ+QDUBNcu6ZcZ6a9jQ0klZLjGr7EyD+LEOt0dL9vcDGJDJQ8okQLslC70mEmo/w8e9mqpXnZ7s= X-Received: by 2002:a05:6902:705:b0:695:b3b9:41bc with SMTP id k5-20020a056902070500b00695b3b941bcmr23371622ybt.426.1662129963987; Fri, 02 Sep 2022 07:46:03 -0700 (PDT) MIME-Version: 1.0 References: <20220901173516.702122-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 2 Sep 2022 07:45:53 -0700 Message-ID: Subject: Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal To: Peter Zijlstra Cc: Andrew Morton , Michel Lespinasse , Jerome Glisse , Michal Hocko , Vlastimil Babka , Johannes Weiner , Mel Gorman , Davidlohr Bueso , Matthew Wilcox , "Liam R. Howlett" , Laurent Dufour , Laurent Dufour , "Paul E . McKenney" , Andy Lutomirski , Song Liu , Peter Xu , David Hildenbrand , dhowells@redhat.com, Hugh Dickins , bigeasy@linutronix.de, Kent Overstreet , David Rientjes , Axel Rasmussen , Joel Fernandes , Minchan Kim , kernel-team , linux-mm , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662129965; 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=LfUeyyDPya+VM647W1kMLyuQpfGce9UnDrfOM4ed8c4=; b=5LYwK0ojop17oGBY/L6Mz+dksZxf8JOoA6UbuHsWpoG5VD1TR2xojFHNa/gfj0Exir3bUT 0RMYM0fwtpZjJWVNj637Bh7vqsSPfn/QSAdvlUAgaCrueokLJcE4Bz0eRCxAPUGMJfbgqi nqQ0lD0/5HtIwFYAKdwc7IcDDWaAEbM= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=e0bgvUNt; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662129965; a=rsa-sha256; cv=none; b=qEtZzNDfpinlBR7mwncMSUZOb1Cf8K0iIioSFDc7ylfTm3sNVBJckIWuoSzsNNy59aqSt3 J0xZN4uh6vGVDl81iz5n3W98P24qr1B694CARtmD288YZQl8JAaJRfe/yOkOdpjSOSnBoa oBwkXepwPLHvaqVLQOrTvJsg6aqTS2I= Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=e0bgvUNt; spf=pass (imf30.hostedemail.com: domain of surenb@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam08 X-Stat-Signature: 59qdsqz4fzsmc8g1iubgmoaysapdggcy X-Rspamd-Queue-Id: 070798007E X-Rspam-User: X-HE-Tag: 1662129964-364103 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: On Fri, Sep 2, 2022 at 12:43 AM Peter Zijlstra wrote= : > > On Thu, Sep 01, 2022 at 10:34:48AM -0700, Suren Baghdasaryan wrote: > > This is a proof of concept for per-vma locks idea that was discussed > > during SPF [1] discussion at LSF/MM this year [2], which concluded with > > suggestion that =E2=80=9Ca reader/writer semaphore could be put into th= e VMA > > itself; that would have the effect of using the VMA as a sort of range > > lock. There would still be contention at the VMA level, but it would be= an > > improvement.=E2=80=9D This patchset implements this suggested approach. > > The whole reason I started the SPF thing waay back when was because one > of the primary reporters at the time had very large VMAs and a per-vma > lock wouldn't actually help anything at all. > > IIRC it was either scientific code initializing a huge matrix or a > database with a giant table; I'm sure the archives have better memory > than me. Regardless of the initial intent, SPF happens to be very useful for cases when we have multiple threads establishing some mappings concurrently with page faults (see details at [1]). Android vendors independently from each other were backporting your and Laurent's patchset for years. I found internal reports of similar mmap_lock contention issues in Google Fibers [2] and I suspect there are more places this happens if people looked closer. [1] https://lore.kernel.org/all/CAJuCfpE10y78SNPQ+LRY5EonDFhOG=3D1XjZ9FUUDi= yhfhjZ54NA@mail.gmail.com/ [2] https://www.phoronix.com/scan.php?page=3Dnews_item&px=3DGoogle-Fibers-T= oward-Open > > -- > To unsubscribe from this group and stop receiving emails from it, send an= email to kernel-team+unsubscribe@android.com. >