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 83D42D3ABF4 for ; Mon, 11 Nov 2024 23:19:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE9636B00CC; Mon, 11 Nov 2024 18:19:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A9BDB6B00CE; Mon, 11 Nov 2024 18:19:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93A736B00D0; Mon, 11 Nov 2024 18:19:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6F3906B00CC for ; Mon, 11 Nov 2024 18:19:37 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E7AD11601D0 for ; Mon, 11 Nov 2024 23:19:36 +0000 (UTC) X-FDA: 82775381934.23.7F04FF2 Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) by imf11.hostedemail.com (Postfix) with ESMTP id 6945940007 for ; Mon, 11 Nov 2024 23:18:44 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qnoPrOUQ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731367000; a=rsa-sha256; cv=none; b=y/L7+TNCZ6+/XSnPXuAl/EFG1GtrG6afD6BXjPllFgOxpKQhnf0vbjRH0UScaIY40GdEwq H/0W4n7/FkyZxFIVlyXcbrf63z7pqFpp1t911cxA05GNgW4QQk62quxTB0Z9P+MF8JRt58 /ulZ5TLNnt8hh5j1Wr0Asdymv+iNKBU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qnoPrOUQ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.166.179 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=1731367000; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=cckibaKiKNSOfZ/m75CIbHIvVaalZEyDHgB5Y3tCiHg=; b=FiPJEm+46+F9qn4gXpXlquqJjcX2X/gzWRssxd+JTxZ/lFA4GoZsNwv2L34pSJ87Z9TfZE 7LnmL/7qbWTvb/x/F138aMEmCrCkz1U/ec7TrYZT82JynQ8QnYqWTuY1b3FwYbMjceu4T6 ZbEZRHW1Ngb+8ZQb3m1f1NyuzXIhDY8= Received: by mail-il1-f179.google.com with SMTP id e9e14a558f8ab-3a6c3bdbebcso19475ab.1 for ; Mon, 11 Nov 2024 15:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731367174; x=1731971974; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cckibaKiKNSOfZ/m75CIbHIvVaalZEyDHgB5Y3tCiHg=; b=qnoPrOUQgynJaz26gOJK9EAKmV2VJ8wqdh7hg5i+yBcoInsxdhLUCkj24xIXkrhvxj bkp4QgEV63LwooCL3K2qoVLOU1hae30Vz3b8YTYl/HQJU/V11lhJZWylYEgry1R4MH8j 7uiAl6eW5QK4xVjuIL6jZPkz8io3nJW3ucQu1o3iS44mBKZId/aLuE95wR7nl/NnZc0h zXQFTlAZmQeWkG9LhGpxNNwwTp16W7/eMdq0GK75ksruHdmxrtHGJGFRcuUiBZyFVyge KW/xw9NegY/GGoXq3mXYP2Zx6HfKx6bqVoW3y0e4RFzfaoeoSbxV1dVlwcmvcFt1WRez 5WGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731367174; x=1731971974; h=content-transfer-encoding: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=cckibaKiKNSOfZ/m75CIbHIvVaalZEyDHgB5Y3tCiHg=; b=C3Tys2+ETwiMDOFvhZ80B2XKWZN/b0E0+FgaaYQrORwMcSbzXRr5M+eCoEeh0WS4fU 1C6EFpM4i/gwWYMyGsDaSdA3MFHEGOJmvfQkRjXkh/0Yo8jtuunn2Lg7XhVpYGq2V2hc 0824bRKJ/r3nioGpR78J6HtRiOiOLlEGQpkYGmlRGaFiUOht8J/qNCtS2Nxs+imDWw4o 7CQExVk+VaF/47lgCmmyLaaKNaABCrPrZp+pQx4q30rAQUkhq5l4Vx+deWWBlxjzJfun caQBgGxHRkfc+OHhqC3os/xukHuxsHgYksd3rf7NADjIAz3TQZGPpQqInahiuppaFseK YCdw== X-Forwarded-Encrypted: i=1; AJvYcCUGJQo3u+PF31DzE7C7N+nRRT/48IMDLoCj+h4CRI5/i0d38Rs/euFFkEQhZCYUKNzm7UfdOqRHhg==@kvack.org X-Gm-Message-State: AOJu0Yz7RCATN/FYIMxQnb0l/GBhyZlp45bpccU6sHIiRF8mJvFKuUTc ZJNxddFyGU2ugSV5V+4yqDaFjiFolonK/KkzuUmHpiFa55GiX+VHsDsDGkPiTAK8JpNHCZwG7zD F9eMHDGKJv6WYd5oUYk2g2qJ9vNw5iTyxCD7E X-Gm-Gg: ASbGnctFIR0Rdpl+qNGtwRGbIGZI+ZNIT8RURQuUbqQ9Y8duQUHondYZh9chjEyUj8I dvs0lCQvsjvO0C6Y6X80rP13jdwfVOMY= X-Google-Smtp-Source: AGHT+IGeh9r23ezmUSk7kTjdXoTQAzjQbjGWun7emtM/lg8qMNJnpD269veSSX8de0tnPclONJLxCn+Nr4lnTv7OXmY= X-Received: by 2002:a05:6e02:1b06:b0:3a0:a9a3:8a74 with SMTP id e9e14a558f8ab-3a70c4ba422mr1007725ab.15.1731367173840; Mon, 11 Nov 2024 15:19:33 -0800 (PST) MIME-Version: 1.0 References: <20241111205506.3404479-1-surenb@google.com> <20241111221839.w4rqqlvvkm42jdgm@offworld> In-Reply-To: <20241111221839.w4rqqlvvkm42jdgm@offworld> From: Suren Baghdasaryan Date: Mon, 11 Nov 2024 15:19:22 -0800 Message-ID: Subject: Re: [PATCH 0/4] move per-vma lock into vm_area_struct To: Suren Baghdasaryan , akpm@linux-foundation.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: st676qofgbo6k7dpt8i4p6hbtgqonrjj X-Rspamd-Queue-Id: 6945940007 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1731367124-52722 X-HE-Meta: U2FsdGVkX1982xt86MPdnqgmH9429CSmGmgd904vRNbaYSc21Noe+FZSRdKcy5wXvyBIhAAh5LPMxSs0OZ0+b1n+qvsdRTkkgHhR18LS/xpXKK/8F+hpCaxAI0szjz7wPpxKf8glBTuRouigfhc4zshlK+QJxAo3EifjQ9T4IN6zsh+HywiSiHVMyb9MfqMQj1ORtiFhxeK9mxVUBV/ygzohrMzGbLhqvmLi4+8WPSXkrL3cvUT8tPmdJAA1Kh0QiH5L+Nj4rCCUqn5mks0TWIfuok90CsI+nC6Ioc5Ld0pq4OSfOk6+VYE7wIqhxg18DAAOS5XlnJIWe1d6Puckuad74iRiGJNW85t8OlAkw5m8A/pXEVAmKETcAmncjJTaoFgPTpvLr1k5XDQ2hUtOQtTJnlashRj3Q3TY5uaQDj+0kkttUKfmUEP2u9RiwjPQBOK5o3JDBryJ8lpXmXqOZoZV+V1IBX9IR6E5X0D9Vb2ImuaQsicO5mBzqmbQ6XKXLCKtBDJtyfKcVDpTqYOC1g86Qu1lfdy78kbm4ZrFaXEONIAnO9Jfk8a/sBSbNYBjxaEqHwb0iwZ1PyRPX82yyXOlesJ70KrDT/3Beed8crGhRPQBOLD9bxhJN2p/oMAj20foq4GLCprkd6Ngf6CrHnjt9uInxJ0LURnXZWKudUMqtw82zDFCaayPRSy13OBsrcOXTtGOlJsA3v7ZBPRtHsq/4GjvLCkmUwVQhDVsU/g0wzNDzUGLWmWDS8nqE9ZvQeHF0Uk3Gok8DT2GADpR6oqcH41eq44KWe/yC/APHqcCfh6aEC5AngTSxG9Z+640VwsAb9HmiC35/C1xXTZ4LrhO802of4nbPkMCp6bK29DG/zn8Abz8vxv2rdWyjOp/2QMHlMtPfht4m1e9MsXO5Zne058zxO4cP6Vcyq30jRPFz6kRM2z3v6NAqIVUtsB4aorZXAiljr0FmTCkkP2 oeHhwGLo mTipQiB7wXXErAL9oCdbk8+jsB5CKJ/KA9CzG+tuASyrucGlTVxmvkvpsUFRarBFwMaakqpV6JFarTk0B4yUAKhipr6uzM9kf9waiaoldQN1NuoKFKTmoAz8misB3syh1bwMhxwjM8coc3ZmiHPVbhNVXPIBksixR5lPz23P6il2fjueDAkHDve1u2DzEtczuH+ajd2da+4xJhBN9HWT9dUJgZFTLrRFmRRMbZCpu0/g7j6+dI3JuoJyJw3LOz6q6P+U0C4+MbwH73rLoxlpdKzsy/gnhSiDaItKB X-Bogosity: Ham, tests=bogofilter, spamicity=0.000223, 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 Mon, Nov 11, 2024 at 2:18=E2=80=AFPM Davidlohr Bueso = wrote: > > On Mon, 11 Nov 2024, Suren Baghdasaryan wrote: > > >To minimize memory overhead, vm_lock implementation is changed from > >using rw_semaphore (40 bytes) to an atomic (8 bytes) and several > >vm_area_struct members are moved into the last cacheline, resulting > >in a less fragmented structure: > > I am not a fan of building a custom lock, replacing a standard one. Understandable. > How much do we really care about this? In the Android world I got complaints after introducing per-vma locks. More specifically, moving from 5.15 to 6.1 kernel, where we first started using these locks, the memory usage increased by 10MB on average. Not a huge deal but if we can trim it without too much complexity, that would be definitely appreciated. > rwsems are quite optimized and are known to heavily affect mm performanc= e altogether. I know, that's why I spent an additional week profiling the new implementation. I asked Oliver (CC'ed) to rerun the tests he used in https://lore.kernel.org/all/ZsQyI%2F087V34JoIt@xsang-OptiPlex-9020/ to confirm no regressions. > > ... > > >Performance measurements using pft test on x86 do not show considerable > >difference, on Pixel 6 running Android it results in 3-5% improvement in > >faults per second. > > pft is a very micro benchmark, these results do not justify this change, = imo. I'm not really trying to claim performance gains here. I just want to make sure there are no regressions. Thanks, Suren. > > Thanks, > Davidlohr