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 3EA0BC74A5B for ; Thu, 23 Mar 2023 21:12:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 84A1F6B0071; Thu, 23 Mar 2023 17:12:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F9F56B0072; Thu, 23 Mar 2023 17:12:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C1406B0074; Thu, 23 Mar 2023 17:12:58 -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 5A21A6B0071 for ; Thu, 23 Mar 2023 17:12:58 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2F882140170 for ; Thu, 23 Mar 2023 21:12:58 +0000 (UTC) X-FDA: 80601412836.09.96C8D5F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id 7AA1F12000B for ; Thu, 23 Mar 2023 21:12:56 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=0RrW82ha; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679605976; 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=b95nPH1Ao1aL3eEc8G4lQQlhd5Z4Jwk2rDIvct66dBI=; b=g0buFBER8m7V3XMIb0cvTxMbDweoA7yi8b0+HjJINaOna6C/ZLdfh0brmIn3Q3EdgGnGn5 gy520TmGhmOIAcTTlcawe6znFK4XPVOQ3CeTU1Vz9dwST81cKu/QA67c2bz0fwuDS6ncS4 L1WNsB8dPnK7NEgZ2oC2l8AexuCSs5o= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=0RrW82ha; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679605976; a=rsa-sha256; cv=none; b=6NNJB6sDlQIXBdIHQ8U8vENmUse0NrMl8hESBpBXjLZkSM63TvDb3Qn2Mu3vxvNpPKD2QM PMxE36ZAtMSh7a4rk6PRePdm8TBkIn5LLDzXca9FFquvqdEvRSxhnXH9ot5hmH7Xp2q3yH G1JEX8VtuuG1pnrJw5R6MgLxWEOncq8= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6E9E2628CA; Thu, 23 Mar 2023 21:12:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D4E78C4339B; Thu, 23 Mar 2023 21:12:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1679605974; bh=Z0sInuaH1aKsCzVuN3S/I6jdhr0FX0yp6ICyU7bBNig=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=0RrW82habQUn3iTNR+722021vuT109WUE/b+asyJPATK4F8V/gfZBzYAZ7BoO/cTf G6TwY2KPsVQB4NWHY5WZMhdoY1aJoyKl6Cv/memxq+gDXhV7D/jiRiwGTkPVXvxs2C UoDY7v1J4cQZ4vGLriEe/zoGjcKfaa80ET9DD1hI= Date: Thu, 23 Mar 2023 14:12:53 -0700 From: Andrew Morton To: "Uladzislau Rezki (Sony)" Cc: linux-mm@kvack.org, LKML , Baoquan He , Lorenzo Stoakes , Christoph Hellwig , Matthew Wilcox , Dave Chinner , Oleksiy Avramchenko Subject: Re: [PATCH 1/1] mm: vmalloc: Remove a global vmap_blocks xarray Message-Id: <20230323141253.d5a626f5cbe03adec3d88add@linux-foundation.org> In-Reply-To: <20230323192111.1501308-1-urezki@gmail.com> References: <20230323192111.1501308-1-urezki@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 7AA1F12000B X-Rspam-User: X-Stat-Signature: n568aahrjfwm34ypxsm8hfjtxouso7zp X-HE-Tag: 1679605976-662198 X-HE-Meta: U2FsdGVkX19SOuI0WV4JDHik7ML7U42WV06sBu1yNpeWxf38PVvliAZFBj/aavPVMhbXzVBZV9HTO+GZNy1UTaUSiD7U63Gk+kmJQtxRmQtLR9zwMChXfJytnyjLlQxl29Ra21F78Qy2Dc8IDH+kBg3xEKss4ibsUVXWIUVQCq1XMqwpM+kvt0ThCwC0l/Ky6WqiWJTOgKnqXZ9mOKP8oJez6cUKLZ12UVgByobEnsTk5UpB9r5HpQBMSwMMrKl7bl0gfiBzwfoopLQvNq1ygqG8lhOpgeGGg52yro4cnkLFxVkCjcoDawUiYMvMF0ZwWSQtU35uucuK2atpo5hKKaaoo0xzV0AGTGKw1XQj3pRJTjYR+v9/hxThtC1csgwgx+axsEQV+SMGKu9V1DqPPl4dSelvHqc/RtmJn9BkTQbfNmCU3+wqQ2gmXoI+SspZfF8HCOHGQxszpUb0b9tsdHlL7iWgtTBXj0/57VLQpGJQXx6Q2JPtFvk4RXQThedGvvb/XIDi/TaSQ23rjvOGnZLtm7GuqACLVT0sT7IIP3SwsT5u/+CwuaAeyAaDot7sRYeIxibzKnEPiCppIk7fP3Dcf8d5n7N5pwH1Pr3r7+qHiSwn0wSS2qSP1iVxuWQzZemd+DJbq/20Mjiw3YwDwjr3tvk1eRuOQgkbVWZHfH73gr5AfUBzHoj+D3KS88Is8ppQIn9Di7/WYciRHxtFhraXv94qRomNqjUYUtSMMCGyVUvDAtsykKPFJDLurvHi0zjch30PPMdTwISIyC0gl6zXjX5k1yDis3gtwb1cjcCckXP2Q4qbs6p/olNqU0K6wlTuz79s3YT6KMEvuMoJXSD2ey2tKCrkyL7qthcrOOmrr6BILagNyOyRwRd6BbNiXx8nl/xqy9gHRtLYoaWkLnMI3zK4lWRuh/sFdXPPnQK6tb+OIlxsz4nBV3FoCglA62qy5nBToNf3vB6yJVW m1WoPRBJ bhBJmzTz4PrF7mIGr2jQQYCPqeY13sEcGzsnavD13WK7BS0zBuihdRudFyayLOpD5B2hmjreygwGXjelQXwzjD0CP/b9YadtZt2qORRAb+nMbC6WVhZN4vbu3aAnT7JtmbhXBPWk5Vg1hEB3b1h2TZ+60jUYWvViyqqpNNiDRNJNA9YVm74QZ4krjFewmbfsNf9V96r3bT4RM831/qBHbMisMDVr/8QLPnKuozYkIIdha59PB8xwmI6nFlrH1zyqIg+Lvj68GwkHbLFXj9tysl0vWjemeqObKxACdTUROqS85nvvjW0wR7apDkHOuVWZb1UVHr/8cs+FAJ5xqOrCSeD0cVfHM6acKfIcKgPLBn26G0aaln1iA7WVOdQ== 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 Thu, 23 Mar 2023 20:21:11 +0100 "Uladzislau Rezki (Sony)" wrote: > A global vmap_blocks-xarray array can be contented under > heavy usage of the vm_map_ram()/vm_unmap_ram() APIs. The > lock_stat shows that a "vmap_blocks.xa_lock" lock is a > second in a top-list when it comes to contentions: > > ... > > This patch does not fix vmap_area_lock/free_vmap_area_lock and > purge_vmap_area_lock bottle-necks, it is rather a separate rework. > > ... > > static DEFINE_PER_CPU(struct vmap_block_queue, vmap_block_queue); > > ... > > +static struct vmap_block_queue * > +addr_to_vbq(unsigned long addr) > +{ > + int cpu = (addr / VMAP_BLOCK_SIZE) % num_possible_cpus(); > + return &per_cpu(vmap_block_queue, cpu); > +} Seems strange. vmap_block_queue is not a per-cpu thing in this usage. Instead it's a hash table, indexed off the (hashed) address, not off smp_processor_id(). Yet in other places, vmap_block_queue *is* used in the conventional cpu-local fashion. So we can have CPU A using the cpu-local entry in vmap_block_queue while CPU B is simultaneously using it, having looked it up via `addr'. AFAICT this all works OK, no races. But still, what it's doing is mixing an addr-indexed hashtable with the CPU-indexed array in surprising ways. It would be clearer to make the vmap_blocks array a separate thing from the per-cpu array, although it would presumably use a bit more memory. Can we please at least get a big fat comment in an appropriate place which explains all this to the reader?