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 B062BC52D7C for ; Mon, 12 Aug 2024 16:30:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1598A6B008A; Mon, 12 Aug 2024 12:30:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 10A646B008C; Mon, 12 Aug 2024 12:30:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F13E76B0095; Mon, 12 Aug 2024 12:30:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D1B256B008A for ; Mon, 12 Aug 2024 12:30:39 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 81311A02B8 for ; Mon, 12 Aug 2024 16:30:39 +0000 (UTC) X-FDA: 82444131798.17.792CC58 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf17.hostedemail.com (Postfix) with ESMTP id 7197040003 for ; Mon, 12 Aug 2024 16:30:36 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L34mUgWA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723480185; a=rsa-sha256; cv=none; b=a+qiFYZbvpxOj/MnVtmgMKsZb14/OE1ZaG3CuGk4t7jVZmv/uR9Gaxb9niEvrqGx9o75Um 1rL+2gLsdqNV95MDO9/Y9dXB0awXVGsC+RVWIkVyhheqMCoSikSIVscbe3JEGBRPYCiPvJ MqAzQLKMqW6UQtyLzYx8D805DWWmgaI= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=L34mUgWA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723480185; 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=zh/ZheNui15fU6+AXHk2A7ofzsw2gwL6IA1lX6l2+yg=; b=c4Ie+SZXdfZdUhfYveglQeyUd2+8fYxYDSsuGeWEePMGZeYrLvzxmdFuHFqXMBkPHx9M+p 8cQhylorNe+ZyGk7aIL3ZqyqMfKiVQGLYOBKuIxuKaroKnGObQ2neiLpUhjSVtqtAdy/Av DQf79VuljCHOr0I2JOzGnq1fWjHSOjM= Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-a7a8caef11fso513375666b.0 for ; Mon, 12 Aug 2024 09:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723480235; x=1724085035; 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=zh/ZheNui15fU6+AXHk2A7ofzsw2gwL6IA1lX6l2+yg=; b=L34mUgWAwM/Ai0gE5gnWYnfzQZhL74XSIecQDEisgRTgSJjwO4Yh6WNCOXWWcQQAXN /8pygJj+JiG3HD8iTARuSA+KBpaxmgop+fzjZmE4epUgrOUMR5We4f+TBt+TvM/Aewzt JyMchRlLF5O3qjXgqnSpbIiYrlYQ+YZeLC9OGxliCSdOTssdYSndjmdkZOIbNgdwVFwh 5NKb77lZMigvP03EBJfZ/F9ofZrHSRhJebd2kyCn4zmXo39A7kdx45Ehxo/4m5oL7Ksk lFV6RqXYe5FEIkM5s76B2TUQo8Xyu4kuOPJ6kq7/Nx0vbidS8+OOaJI52oh4/ded3hy3 cQwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723480235; x=1724085035; 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=zh/ZheNui15fU6+AXHk2A7ofzsw2gwL6IA1lX6l2+yg=; b=IjQOsu3SsgvmlujboDiwn2pW9Hxm/sWlCzLJygkPJiz/GvKgHOb6BTR280s2sy8PZ7 DBw8/hWntVjtqy4v/HfjC+rH+McjUWkuWe4hggFo5DNOcVLW8uR51MlLFi3h/EgR+jGs 853C4m1CKs+dzyEmoL8D+1F2hAXWTpHYHL4r+hcpI7BtwAXeaFfBSS0uAmIg9o4u2rdz TICBvmtLxQzBwYpTpWCDFTWfpmE4vn7xgbXKXEGOTLBLxItS0T0yOqNY5kAv6P8VSj9s 4gQu/1McOUt4mCHh28DlAY1JbQuTlZml1xxke0Les7YdOK3/WMQRGF/JyBJsRI2U9LqD 6deA== X-Forwarded-Encrypted: i=1; AJvYcCVHejkc8V1VrTeiO5TxEj3vjh3y0MHK0PbJi8el6Q4M791oAAVeRGTp/6R4n+r1lnVumayOxUB6WlR150rMq+em4wA= X-Gm-Message-State: AOJu0YzpcexW/ti5lwO3DV9qu7y5sTBh4yQYDkBsqIA9mdOT3YYINIOi Rx3mbUP9n18DGPhyGfaEyc6YVjlYb1SFv7xJaDUD1XBM4kFTm/FALLh6usBue+Uc4NGYwR89Cur 3GTPzP5kFUwjL2rmya7FcmbqdtWQ= X-Google-Smtp-Source: AGHT+IEi3ijVRmgqPYAuk2JNGk5MQ8Fw3FiDN1n6sSx8/RjW+0p8rwr1AmyNmtT1vWdTmXSjAzYI+KL4iz5My99rCdU= X-Received: by 2002:a17:906:bc19:b0:a77:c84b:5a60 with SMTP id a640c23a62f3a-a80ed1c2522mr67312766b.26.1723480234262; Mon, 12 Aug 2024 09:30:34 -0700 (PDT) MIME-Version: 1.0 References: <20240808185949.1094891-1-mjguzik@gmail.com> In-Reply-To: From: Mateusz Guzik Date: Mon, 12 Aug 2024 18:30:22 +0200 Message-ID: Subject: Re: [RFC PATCH] vm: align vma allocation and move the lock back into the struct To: Suren Baghdasaryan Cc: Mel Gorman , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Liam.Howlett@oracle.com, pedro.falcato@gmail.com, Lorenzo Stoakes , Mel Gorman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7197040003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 4595q3f48dfg3idk75s8q68kgfss53p6 X-HE-Tag: 1723480236-731816 X-HE-Meta: U2FsdGVkX19nWLNtPr45kkjE7+kJNxYf+m+t8jsOWweeVYAHE+WhubU8uVVy6DrdTQ4P7Ll31lpcTrT0PGQ6mEeQvQqTeiDLRWepvNbSgkOsaunV/dkSLB8I1OBh2t7i9vtUNHjTYXUz9MXa64XUhIZUqSjFoExyqc/mWKtHwpHP8kNdLkwkvCTnvnmiNB2kGNtuqOJw0L7uPuwr8O0mehzNmTOpjikVUkML5PINzC/8s4Q0i1bHfg70zaJv6u0MfnF6yj2yAnZxUi/F97cNIn5QMDLY+8naPisqvEdSZdsXQdQtSKLtpQMWHkIr+65Tt+I1KmLOqDKGDWNXrQgvlb3Oj5OTsVz6aKP3uu28LIU50ciWj+CzYFcpdjvDQ+2dlJxIaeqiXRdO0Kr+hb20suywQR85SJUw6w/hg3zZuiLNA5bMAaPfOemvCk3jSG6eL3fZ26dIeSdivQ8OmnlELWcOfUCJWOSJUn3bCdiMnwwUdG98JulakS+e/PKowWHqaNrdyQsZitw1Dts9SPL4L/Qwd+Uo/s+Whq8AtVSUF+ZMrKknjmU09PMg/x2gAPKAh398MlxcfooNyyrc3Tb04L3o4yf/9tdFX66CmHtsNY0tYmwj6d2/q30NmLwn2axM5k2fI82TuebI9xmFNuR/5nK5DfHyDiHyqBFu1Kb9vhGNEa6cUCfZA+e31lzvTTKWEYo/NmBS8aejgKq0IlNkmI8FIstYDHDF7fsp9nqEGD8jBWu+kt8L149/H6slJYYBcaD8QzT4OmmJ5Ll+Y8XrEnV04zYpetTtm4r31hH3k+p+qHT9+g6PF+cRk+MPujbk/OMlmyH0bYTaFTD107MBHzeHttrVr+Hq5zy+mr2u1dpUrjhyD0G58KrYJq8ze7AP1Xx3zzm02bozne0ggrrpRTHJr1bMu7O1I5LuGDdHF/8Mdi5NuvZGbJWX6DwD3U/bfUcMS9nA8w6CYyuem6W /uVP6kIg frxC/8di9xTBpMX87v1EozNkzpeiygOrN/w4dX8b+/YutRsHIfliTg9A4JCmB2ZhmAXfX6rzW/iMxwTBkawz9KMJMR5OBjN41w/g698a1dkc3tAJPOc9yAQvYcwW8Jf2DY2FlBnhslwR2BPlrEtsZDpCyGOs075uIIyDOr76xs+B4etzZRm/XHCLtQnpUmkawFlt4i/KlJRVCaUco02CYdc+InsYNeqZVPm+fR6/2Ad89mHfBqwQaOQsdoW1yKux2jjAKsMm5Y7CWoPJUzMX7noq7N1bFxzbTwFqVaHmWwhfLPkb/UHy9wkQzPg9M/RMRG/K7xniaMcUamdxTbfmwUc1DfAotrKulyK9iqFeWa0moKGQ+v+AIf5866GTHZK3N1vAVMAX+7fgEU4c6/+mBLLb8OdBuYlGeYtlG X-Bogosity: Ham, tests=bogofilter, spamicity=0.000759, 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, Aug 12, 2024 at 5:27=E2=80=AFPM Suren Baghdasaryan wrote: > > On Sun, Aug 11, 2024 at 9:29=E2=80=AFPM Mateusz Guzik = wrote: > > That aside as I mentioned earlier the dedicated vma lock cache results > > in false sharing between separate vmas, except this particular > > benchmark does not test for it (which in your setup should be visible > > even if the cache grows the SLAB_HWCACHE_ALIGN flag). > > When implementing VMA locks I did experiment with SLAB_HWCACHE_ALIGN > for vm_lock cache using different benchmarks and didn't see > improvements above noise level. Do you know of some specific benchmark > that would possibly show improvement? > I don't know anything specific, I'm saying basic multicore hygiene says these locks need to land in dedicated cachelines. Consider the following: struct rw_semaphore is 40 bytes and the word modified in the lock/unlock fast path is at offset 0. I don't know how much waste is there in the allocator, if there is anything less than 24 bytes (which obviously will be the case) there will be massive false-sharing. 24 bytes of the *second* lock land in the same cacheline as the first one, including the stuff which is modified in the fast path. iow the locks allocated this way are guaranteed to keep bouncing. I don't believe any effort is warranted to try to find a real scenario with this problem or synthetically trying to write one. > > If there are still problems and the lock needs to remain separate, the > > bare minimum damage-controlling measure would be to hwalign the vma > > lock cache -- it wont affect the pts benchmark, but it should help > > others. > > Sure but I'll need to measure the improvement and for that I need a > banchmark or a workload. Any suggestions? > I believe I addressed this above. If there is an individual who in your opinion is going to protest such a patch on the grounds that no benchmark is being provided, I can give them a talking to. Even then, it may be this bit wont be applicable anyway, so.... > > > > Should the decision be to bring the lock back into the struct, I'll > > note my patch is merely slapped together to a state where it can be > > benchmarked and I have no interest in beating it into a committable > > shape. You stated you already had an equivalent (modulo keeping > > something in a space previously occupied by the pointer to the vma > > lock), so as far as I'm concerned you can submit that with your > > authorship. > > Thanks! If we end up doing that I'll keep you as Suggested-by and will > add a link to this thread. sgtm --=20 Mateusz Guzik