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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4B90BC46467 for ; Wed, 11 Jan 2023 10:04:51 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4NsNZn4qVFz3fDK for ; Wed, 11 Jan 2023 21:04:49 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=aculab.com (client-ip=185.58.85.151; helo=eu-smtp-delivery-151.mimecast.com; envelope-from=david.laight@aculab.com; receiver=) X-Greylist: delayed 66 seconds by postgrey-1.36 at boromir; Wed, 11 Jan 2023 21:04:16 AEDT Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4NsNZ85jTrz3bXv for ; Wed, 11 Jan 2023 21:04:16 +1100 (AEDT) Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-234-ZV2WA3EvMAe4cAYuGqE3Sg-1; Wed, 11 Jan 2023 10:03:01 +0000 X-MC-Unique: ZV2WA3EvMAe4cAYuGqE3Sg-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Wed, 11 Jan 2023 10:02:57 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.044; Wed, 11 Jan 2023 10:02:57 +0000 From: David Laight To: 'Ingo Molnar' , Michal Hocko Subject: RE: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK Thread-Topic: [PATCH 08/41] mm: introduce CONFIG_PER_VMA_LOCK Thread-Index: AQHZJaLQcQ36PXeL+0+vNNlIqTvBHa6Y+0jQ Date: Wed, 11 Jan 2023 10:02:57 +0000 Message-ID: <6be809f5554a4faaa22c287ba4224bd0@AcuMS.aculab.com> References: <20230109205336.3665937-1-surenb@google.com> <20230109205336.3665937-9-surenb@google.com> <20230111001331.cxdeh52vvta6ok2p@offworld> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "michel@lespinasse.org" , "joelaf@google.com" , "songliubraving@fb.com" , "leewalsh@google.com" , "david@redhat.com" , "peterz@infradead.org" , "bigeasy@linutronix.de" , "peterx@redhat.com" , "dhowells@redhat.com" , "linux-mm@kvack.org" , "edumazet@google.com" , "jglisse@google.com" , "punit.agrawal@bytedance.com" , "arjunroy@google.com" , "paulmck@kernel.org" , "x86@kernel.org" , "hughd@google.com" , "willy@infradead.org" , "gurua@google.com" , "laurent.dufour@fr.ibm.com" , "vbabka@suse.cz" , "rientjes@google.com" , "axelrasmussen @google.com" , "kernel-team@android.com" , "soheil@google.com" , "minchan@google.com" , "jannh@google.com" , "liam.howlett@oracle.com" , "shakeelb@google.com" , "luto@kernel.org" , "gthelen@google.com" , "ldufour@linux.ibm.com" , Suren Baghdasaryan , "linux-arm-kernel@lists.infradead.org" , "posk@google.com" , "lstoakes@gmail.com" , "peterjung1337@gmail.com" , "mgorm an@techsingularity.net" , "kent.overstreet@linux.dev" , "hughlynch@google.com" , "linux-kernel@vger.kernel.org" , "hannes@cmpxchg.org" , "akpm@linux-foundation.org" , "tatashin@google.com" , "linuxppc-dev@lists.ozlabs.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" From: Ingo Molnar > Sent: 11 January 2023 09:54 >=20 > * Michal Hocko wrote: >=20 > > On Tue 10-01-23 16:44:42, Suren Baghdasaryan wrote: > > > On Tue, Jan 10, 2023 at 4:39 PM Davidlohr Bueso w= rote: > > > > > > > > On Mon, 09 Jan 2023, Suren Baghdasaryan wrote: > > > > > > > > >This configuration variable will be used to build the support for = VMA > > > > >locking during page fault handling. > > > > > > > > > >This is enabled by default on supported architectures with SMP and= MMU > > > > >set. > > > > > > > > > >The architecture support is needed since the page fault handler is= called > > > > >from the architecture's page faulting code which needs modificatio= ns to > > > > >handle faults under VMA lock. > > > > > > > > I don't think that per-vma locking should be something that is user= -configurable. > > > > It should just be depdendant on the arch. So maybe just remove CONF= IG_PER_VMA_LOCK? > > > > > > Thanks for the suggestion! I would be happy to make that change if > > > there are no objections. I think the only pushback might have been th= e > > > vma size increase but with the latest optimization in the last patch > > > maybe that's less of an issue? > > > > Has vma size ever been a real problem? Sure there might be a lot of tho= se > > but your patch increases it by rwsem (without the last patch) which is > > something like 40B on top of 136B vma so we are talking about 400B in > > total which even with wild mapcount limits shouldn't really be > > prohibitive. With a default map count limit we are talking about 2M > > increase at most (per address space). > > > > Or are you aware of any specific usecases where vma size is a real > > problem? >=20 > 40 bytes for the rwsem, plus the patch also adds a 32-bit sequence counte= r: >=20 > + int vm_lock_seq; > + struct rw_semaphore lock; >=20 > So it's +44 bytes. Depend in whether vm_lock_seq goes into a padding hole or not it will be 40 or 48 bytes. But if these structures are allocated individually (not an array) then it depends on how may items kmalloc() fits into a page (or 2,4). =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)