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 E1B69C76195 for ; Mon, 27 Mar 2023 07:15:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D8A626B0071; Mon, 27 Mar 2023 03:15:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D397D6B0072; Mon, 27 Mar 2023 03:15:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C01BE6B0074; Mon, 27 Mar 2023 03:15:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id AED216B0071 for ; Mon, 27 Mar 2023 03:15:47 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 7D182AB286 for ; Mon, 27 Mar 2023 07:15:47 +0000 (UTC) X-FDA: 80613818334.10.47D1E9E Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf04.hostedemail.com (Postfix) with ESMTP id 8F40240005 for ; Mon, 27 Mar 2023 07:15:45 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=pZMO2Npi; spf=pass (imf04.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679901345; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=y4AJDK3Z5KJjc6XjtS850Wy68GXbyqouQwIvnNso9Ao=; b=XbGcaOQmzAVkK58ginhwTPiqEHKWmo0H3tqYLbfXVBCDsP28zo/fBV75w8F1I9FT1eiCk3 uxWmgd23lQZZNPHo5bRJhZvWaR/5ZJmmF+tPIjAfTa/4z4WbFpvp1UllXK2NOBCU7jNKAE jgC9ceG15FoFMDRfgFmo8TxBxNj7V0I= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=pZMO2Npi; spf=pass (imf04.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679901345; a=rsa-sha256; cv=none; b=vm6hhecZh/VQLxzXQBdK+AYmHy8oIGcNgWHaVNNHU1ZYs2axPbgoHtRgZFVr6hl0QI165M upVU1SPdLWKpDfnK6/SRi3Pes+SPXXmUFdNdwHw6MBWldBU5yT/GSQEY2Vf02vw9oHpDA+ 0OMQhn53vUVXmNr4h/Eo6eGcLUeXKlU= Received: by mail-lf1-f52.google.com with SMTP id j11so9960035lfg.13 for ; Mon, 27 Mar 2023 00:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679901344; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=y4AJDK3Z5KJjc6XjtS850Wy68GXbyqouQwIvnNso9Ao=; b=pZMO2NpiXcDQN+R2yYMSAkikKbHBVhzkh0pDfj0ibCJTOfwD/oj8l/Wx4M8XDI7k21 vxjcXU+nmcajxK2fZOX2pAEg8woJ7X6sazDGdvr5UHAafc/JA5m8NUrX/fnZZUxjyI43 BruB2YshdTHNylx8cBn8uuA37HsLuO5WJR4KaZS4UaRfZCRbSjareZw4wqEwVWMsB9iV /cla9CoBM1VOHNugVyRqx/v2g+er7y8pmvOlQ7swB4OQQzRQBsz25WJeiF0nvskt7w2q SVjQKx3kqux8CWrn9BIZxXyzzLgZb7HyX6DNRUKHBTQ7wyoE+Bw8moOLmUzBKPT1egWb Br/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679901344; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=y4AJDK3Z5KJjc6XjtS850Wy68GXbyqouQwIvnNso9Ao=; b=sCEBLANnNdy11B1+6y+PSQ4qwFQRyNtRiiwHfDrrqRvgbRShY/q4c5+0WVHDcPrkiS WRLEPR5FHQxH8a5zsFUIHIEX1sSm7H0yj/KvNpUyWa+KHe2onz68l5rsldrua/kfe8C1 NNr2nR22k46d6hGrBilGcJ1XSIvh0PILPvOhuWYHAv6lD/H3ZfOJvNOVO+fK8vogi/nI VN/AjxsB3r68ICaFjICZ3q6g1NFi58CxBd7Sk3w6moOvD1aUlnqLESBqpOdaQlt1lKoC iz0TWf6UO4Ll3HiU5rNFmDF/or8tGsI8ErCvC2dFbZgTuCaTbHdSghhX+xoJJv82kA8k 81CQ== X-Gm-Message-State: AAQBX9dINWw+CL4NTJ2Fc1zhl0XTz33cJrHrssKmN/iisddUFe2B5Eso gqlTVZhrBtqdAgH3Ub6UAds= X-Google-Smtp-Source: AKy350bsiS7UIvc6+dNNGbVLnD+KDO94bUHAF+znwuNGV5WANy2AALBtlr2nC/Aj5z/MN0h9/ogo/A== X-Received: by 2002:ac2:4a6d:0:b0:4ea:e296:fe9e with SMTP id q13-20020ac24a6d000000b004eae296fe9emr3025444lfp.9.1679901343586; Mon, 27 Mar 2023 00:15:43 -0700 (PDT) Received: from pc636 (host-90-233-209-50.mobileonline.telia.com. [90.233.209.50]) by smtp.gmail.com with ESMTPSA id r8-20020a19ac48000000b004e8b90e14a8sm4571052lfc.25.2023.03.27.00.15.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Mar 2023 00:15:43 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Mon, 27 Mar 2023 09:15:40 +0200 To: Andrew Morton Cc: "Uladzislau Rezki (Sony)" , 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: References: <20230323192111.1501308-1-urezki@gmail.com> <20230323141253.d5a626f5cbe03adec3d88add@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230323141253.d5a626f5cbe03adec3d88add@linux-foundation.org> X-Rspamd-Queue-Id: 8F40240005 X-Stat-Signature: cz7y7d8jddte4y8io7zcdu8pwz66zpm4 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1679901345-898525 X-HE-Meta: U2FsdGVkX197TXRzovBF/SKf9RR85UUxc5obH2Mudt4mlWJHpvsUeYBOucSnXY7zBoboVUE0fuVuHc9UmRXaIxBSuvTX12gpVDZu70BnY4s/gvimAjR4fKoiwD4ztcZCPQdNflq0Nz3kYtm5Ue2fA+CS5fHBgmAEBUKihm4VDSYs67wrt1dh/rhpJXlsltoqEW1yU1nVneXifOtkEnl11C9Lwc3TPBhU6kXnwKS6iNZbeGur8wF1ZeU/bnk99zGqWUREnENnc+014WHNUDa2tPwu9K7j71mceF7miO/vo6tDXC1GHe2WulAkXgDBl/+8z1RI0fT1HjM/xiAMax0cEVU6RcMF6gV+YnQwJJK2uLjsYARY3E52x9Z2pN67IHaLP5ilZphdCtvJ+p+ltP987CjaS1EBWTNi06hMPNI8kfst0iAd6I1BPBKglpzAVo4nF7AGZKPQWepiHRLGoOBE3AsrghQTJaX23+unsXxIdywD14zTdLaGAYT1WalYpJzEkLm2ViPT/A7HWVe4yoBoAI02pJ/NAQV9XDAb2Fn2O5CPDQrXjfl+HFBY0NdGf5Ov9yBAuwsaE4YHwTTab4hEm+SqAvPndd9OUcDbOC/OfqqB+AxtQG5DGdYpTlC+OuocFAJkL0A91qkorMkJuGFUYmNa4epf+70hepIB8fsM/6hB5LCpRB48F7H8+w+3XdDt2HyWkZxy3wwHLhI7MEWu2LIiMXFjpZpkKZyJ5ilM8xhj+05gbZTJLjBnEb3ylxpAofQEkXODAg/Gibtmjhf+1YBv30ZSrP8WAsVQ6mg7C76aRlQhPDm8FH+bROqIxWfEdwJdnYLeMuhFY49Sqz0f7VhQXj9e1ANtYzEUwYbo+YJacCjk5CmqQ2gZx9dvpmM/M5GkVFVUmtDkBHtINASXOm9qCfxTFE3JWqslLcIyZF19ku3aZG7oBo1IsGdHtN87tk15DPQN/pYr3RU7aRN ydj4gEcD 707/wIY1ofMkk14GFOOEMfBHaR85qsojjdBmmKroN4oiknPOoXjhRd3t4NCqwV2/irH2dXNoO0wlqsTAUcrAZU4g5U04zTU5wVP0m7GPaAEQpPaJj7GM8UmvKIHcfD8ofFYnYy8JelASK04u4hxLnor0gFx1iXqO1ZPvyaIGMKFnqxpNrcdkvYiNadtDN8+PH4Ik9cV7it4MZen8w2gz1qm+V4Y/J2wB/5K4s14eXXQ4tSg3zH3oaQJqLsnwC+XRw/j4O7eqesknXbiV9W5MmkZ9GfyoTjOXSVY2gl9KVBkTRMEbkIWmKdjFdw6jsmjJiFIyww+XF5W8lLVx9x55c30jcoLhTJbbqINS/iIPjRHTbszn9NCOHeEjgXR5lRsSZIMgNlYugC32DPoYlhULncM1oG1lgLo6Gmfj6iesdj35rhowq43KE1ca9KRCsifnRJ0TMHSvf+xuuEsjCOBampOYUrNhB/Yvs/L2GxR4f8fYABZm48dv/j6MR5V1OQGDfTy3mT+C3KqAnexg= 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, Mar 23, 2023 at 02:12:53PM -0700, Andrew Morton wrote: > 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? > Yep, i will send out a v2 with all explanation. Indeed i have to add detailed explanation. Thanks! -- Uladzislau Rezki