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 0F08FC5479D for ; Wed, 11 Jan 2023 10:03:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8929F8E0002; Wed, 11 Jan 2023 05:03:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8423F8E0001; Wed, 11 Jan 2023 05:03:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E4098E0002; Wed, 11 Jan 2023 05:03:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 5F9108E0001 for ; Wed, 11 Jan 2023 05:03:08 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 311D31406D0 for ; Wed, 11 Jan 2023 10:03:08 +0000 (UTC) X-FDA: 80342080056.26.198AA54 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by imf21.hostedemail.com (Postfix) with ESMTP id DF9A41C0009 for ; Wed, 11 Jan 2023 10:03:05 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of david.laight@aculab.com designates 185.58.85.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com; dmarc=pass (policy=none) header.from=aculab.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673431386; 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; bh=EQqDcarZmRV4ngvFY6Un/KXoITcAGVV2G9Ck1wrE+wY=; b=dibAYgi0y3mb3dBLIhVKUQ5bwWkCzvXrOolC+dcbCNkO0CPGoYWp1DZTUzzawKZ8d2mVEw keJWWvxadSuMJ98tC4Sv6q1fBSSTuO7eoaQwprPx2IyNPnW3IxITT+QgnOV1uIihyBPPJU Vx1CuCS5QLbqVHP5O9v+jzdIkulxLVM= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of david.laight@aculab.com designates 185.58.85.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com; dmarc=pass (policy=none) header.from=aculab.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673431386; a=rsa-sha256; cv=none; b=SuLAdCwwtHGS2emPGypHV8Jiy1jjzVozicEz0pmF+jePn0346hCcYp8UpnU+2OSA+IRMgF zugldpNFc12jwE2K0/p3UDnjir44tVqR0I3Ai9/ZpHcyxINriJCMgWjPlEjfdbVOrq0c/9 IrRFfAuRKKTBXEow+BfnBe5Fv3lsOPo= 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 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" , "minchan@google.com" , "x86@kernel.org" , "hughd@google.com" , "willy@infradead.org" , "gurua@google.com" , "laurent.dufour@fr.ibm.com" , "linux-arm-kernel@lists.infradead.org" , "rientjes@google.com" , "axelrasmussen@google.com" , "kernel-team@android.com" , "soheil@google.com" , "paulmck@kernel.org" , "jannh@google.com" , "liam.howlett@oracle.com" , "shakeelb@google.com" , "luto@kernel.org" , "gthelen@google.com" , "ldufour@linux.ibm.com" , "Suren Baghdasaryan" , "vbabka@suse.cz" , "posk@google.com" , "lstoakes@gmail.com" , "peterjung1337@gmail.com" , "linuxppc-dev@lists.ozlabs.org" , "kent.overstreet@linux.dev" , "hughlynch@google.com" , "linux-kernel@vger.kernel.org" , "hannes@cmpxchg.org" , "akpm@linux-foundation.org" , "tatashin@google.com" , "mgorm an@techsingularity.net" <"mgorm an"@techsingularity.net> 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-Stat-Signature: gzarnmmfez3g1y6dh5aenxeh8d6ho7b3 X-Rspam-User: X-Rspamd-Queue-Id: DF9A41C0009 X-Rspamd-Server: rspam06 X-HE-Tag: 1673431385-795385 X-HE-Meta: U2FsdGVkX19PrBBqLijWotfl7nYkVNF6wa/5W07bdwGKQWfPfUzrgd95ZhMFQjUmJxU3R4oppQP79uHK4IhkFDxNc40gKpKxBPjNHxBMkrrehMimYKeKABZRL56ivBcXxNPWLGQN6H7vvdRVhbpx3TvWiZ/kbB8KQPxCcJibaAGPAr9Kz7w++xVQtnTXhdEt7asldP7cNIndNz5OGwkLLGQ8pznx/CNuATH6n1rf/uFJSen9quhMZu9AzbFAszJJ40U15yFdAAqZ3VIAQkeJtI21KgcBRCy+g+AS+Tf4tEkm3bWgwoKgT/rwpi7L8taAmseceO3sXkz1ETrDGcuDNQzXlLt71vL36j5GmImg9W2s8+4uLc20U+Y2oUDbhqiP1nAYOZwZggKX1WBxc5OKQ74LpybeXw+gnI1ZrsrWpI1n/TrOW/MEdU19SJIuaNBLDuKwN6z9LEcxJ+xI1xEWRLu1gI51O5HcZL0PDfHpIkA2e08rG7h8Xh4sXgtSkeNZyycL6dw2/nSkEVKF73bd49N65UhmDhW65m7NIzSoRxhxgWRTO52dMNG7u/rnmGRm9bf/kbqTfGKhear4sBe4UzVqfdaqmmaidy7H8utkx3WaJIbz5AVrbWzghXmZXOOwpMv4CAo4s6vjAZTlyAZCeg0KL+Lp2k4KLJsk1kOrm8p91MyQKox/tlg+SYvxB0UZdvsn0FykfYF2V0xmI751d4k2+OMNTAurB6Vmz/hob83nx2NdUHhsPWCZsZlk8rtl+0BcbtJwIJEcU32bu5Li8wIo0U/fW/psJSmCFUgV0ueJ9ndPVi69t4SqFtSvH68HR+c8kEUbrcjxFdjTlUIMgmWEupZQSADio/HmqVBeqRLrxXdtYFSGyGlyg9saB3DeqJGbbsGZX4m2wEvksioYgkd7HxMFqKwZXEr2eU0iTglSKNEe/80EX65dk2PTiG5B 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: 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)