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 07660C6FD18 for ; Tue, 28 Mar 2023 16:38:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69D286B0072; Tue, 28 Mar 2023 12:38:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64D316B0074; Tue, 28 Mar 2023 12:38:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 515786B0075; Tue, 28 Mar 2023 12:38:02 -0400 (EDT) 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 443116B0072 for ; Tue, 28 Mar 2023 12:38:02 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EF7C2C08A1 for ; Tue, 28 Mar 2023 16:38:01 +0000 (UTC) X-FDA: 80618863962.21.D5EDEE5 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf18.hostedemail.com (Postfix) with ESMTP id D4E861C000D for ; Tue, 28 Mar 2023 16:37:59 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WqYLaRze; spf=pass (imf18.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.44 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=1680021480; 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=wjEXwKhaB5uFl3dZxEPaq/b2jJkwiE7Oa0Zac9PN6Gg=; b=DovZ7JOs/yf6sqzY5QkmFN8XV4E8Nz13+9h3RwUek2nhrjkEJaKUnSxLEKJAtPgrkrXvdg hqu5rlNZrZK40HmUtoky0nF/6KO5TDnstXVWmBv+NsBLuFVabodMNfDI+mBmKE4AYzdin8 ej2+JTA2cWYyg/ZGDp8nZFH41p+8AzY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WqYLaRze; spf=pass (imf18.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.44 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=1680021480; a=rsa-sha256; cv=none; b=FMs7Jx19ISEDKiUgD3P2rpVhtxcDvmyqkecB+Ygy/e2bbjpbVlse/rBzQ2NUZV3noflbza H6/HGoce1dH+GwI1y6Xqhl2wAK8LNk5e8uUBXQXYF3Uk+aVq0aCCUBXNUcoX9FHsZ6cFWE J5VmK5/ORqolBUezSQHmdZqIkJOg61w= Received: by mail-lf1-f44.google.com with SMTP id br6so16568015lfb.11 for ; Tue, 28 Mar 2023 09:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680021478; 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=wjEXwKhaB5uFl3dZxEPaq/b2jJkwiE7Oa0Zac9PN6Gg=; b=WqYLaRzed+nRGClW0gY75crY0szDDbGCu0MxN1Js7sqmbP1wHFFUH+F6kjWp9PSyyE ayyoqfT1PTylOohJYnFkD8LwDnxGZvwqNm2re+Dh4GP29Q00kFR0zjXpB6TrW3rV3dL7 //3LBNR/eKLjw2gIa0wrGsJiSrq1LuU+qd5nMOWJHya6dFzA09vGW6p9imlbDRWjFSCH d1IvN+euHAASweS0L5e2Ml4gn7c6p6/IkKHNVtgeo0sZEwCbwRgXJESlmoZUfsW+33VJ asvz0M8hQeGJLPRCMr6Wgyi9+j1gcBLbFLrbq43vPJ0t8BoWrgWlKjLZ+o1OUHdS/T/Y /4rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680021478; 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=wjEXwKhaB5uFl3dZxEPaq/b2jJkwiE7Oa0Zac9PN6Gg=; b=2R01Jcr5Yu+qzZ3c38UWlFXLiuBGJEBJ+2QApQBSMupKLtNOYoRbmsO8DSDKSCcYTh mzBO4Mi0UUcWOMi2yI5+2p0G3Ee/jpbilnX7kzCB5exnEu8IcN/njtbzmbCGUnTX0LNa CninoFTeCr+PaBZd+vJDMEaE+CuH1cIG4FEvIaPZA8W7nqiOCOVUaXq4Zg9ZNnTc4de0 ECJn92GKLdVpZ/RKnOM3tkzt81nC5qoOasGwDo5IGvHDyVH13F1m4NBZ5k5Z2jyOQWK5 PD5W08nFt92K5qcw90XUBOyRZ5MOyHIT2Pyx25croPkYbKIIVUSpzN0s2lDg78EyXACV bYXg== X-Gm-Message-State: AAQBX9dRHWITMJ1vC/9ycZEhcJtIaeps8q/dPbGm8/tlCjKLozMG879N jSVKFRL3YJecuO3RYqsc3jU= X-Google-Smtp-Source: AKy350ZUW0Z5/3nIfPHhop5lh2NbfUHDBYgNFzm0v995LUfM87WsfU6K6Z0IcTtowV3lO+tgDBAdJQ== X-Received: by 2002:ac2:5ec6:0:b0:4eb:20e:6aec with SMTP id d6-20020ac25ec6000000b004eb020e6aecmr4743236lfq.40.1680021477918; Tue, 28 Mar 2023 09:37:57 -0700 (PDT) Received: from pc636 (host-90-233-209-50.mobileonline.telia.com. [90.233.209.50]) by smtp.gmail.com with ESMTPSA id w9-20020a05651203c900b004db2ac3a522sm5159100lfp.62.2023.03.28.09.37.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Mar 2023 09:37:57 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 28 Mar 2023 18:37:55 +0200 To: Lorenzo Stoakes Cc: "Uladzislau Rezki (Sony)" , Andrew Morton , linux-mm@kvack.org, LKML , Baoquan He , Christoph Hellwig , Matthew Wilcox , Dave Chinner , Oleksiy Avramchenko Subject: Re: [PATCH v3 1/2] mm: vmalloc: Remove a global vmap_blocks xarray Message-ID: References: <20230327170126.406044-1-urezki@gmail.com> <132e2d5c-0c1f-4fff-850c-b3fb084455bb@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <132e2d5c-0c1f-4fff-850c-b3fb084455bb@lucifer.local> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D4E861C000D X-Rspam-User: X-Stat-Signature: rwxyxqsw749cp8jgxttf9ufntw9jgqbb X-HE-Tag: 1680021479-638241 X-HE-Meta: U2FsdGVkX1/57ZZt/JShqb0ZXA0U5cjMKU25UtKQY8YgYHhv9OE+Yvg7+m3xP5BlKkkCB0Ct8ExEgokzISB8UudMKrqYgCpsFXUx1xxjf9G96hZPvIy2U+6xxcApF1IYMsbk22l66iI6RXbkAutgl9AquCkhkkFzqzMn63NV4UjnfAyvVRSfru7GrDS3Ud3AsV2brs3qnsIbWSlgXeXmDmsTjvp+YrRGD2kNxNctXYBT+osdOwScc6uTK5HxX3c/X25xFal7vFQceMc2oItvaou8IYTeCs2QmQhnwYv9DIZ9ty3L2mYYiR55eL1aabfrwevjCaonJezvWxW+hw6os4rsZMtw9JtXSBckYYNXKwJB7M44Pc1rjuvoUHjH1618mxJh/lPvzquVvhG4zhiij25tSD97GdKPPaala9icEuMhUCNX/DYAQvoNbXm/Z3gBRdzmH7N4PklFGg1JvUQmy3KJ2ewTrPqPsJFbKN/CjOWDYiKvqKlVisSq2KLYnMMNgbP/b650wxWkSnBZ9IH42ERjMo30M/iSkVY5RxoQjb99CjOZlxnP6CSDe5h2dLJq2vpaZAkxs5rGI8JSxva5T9v9vtGYTJrbR0eSu7raJhGRNQcZ9/XTDloykevHFCzY7jo0KnJOmPpaIaTXheoFltty8esdlOJmVK49JUndqgMLH87HVe5VUOin/LJJt6p6N3GmIv9CQdt0nY0nTkcQ2XaJu3dcm9oO7l8y9iIFZVqwz+pe7gkjUm4jms27zNl9JSQT4B0gjpg/X7Ce1ffWjC8lt7fTxaHJevJLltvdKhIbvP3I42m6XtO6DGceeNBS7saeoA4thgonU54voHfFG2ZCJSPfzgDlmRTREbfXiR9/HwbJqXJmTwy6fw1eiXcJxgpq62tkVhpDUsuR3ykTEqXNDoVTkHLHAvWpWemL21DVK+bdInaGHcHDYkk5f4Q5vf5meFF4QZXebAXnF2I wtdwA7Zw KwEYtqz61nL+uYIkrdTPAtucjbWYlbPSNOoan0qU37iofC2ZOeHqbATcPB2mPdQW4M52A4kUHE2+77D5MUelzf3q66IGMipwtZ3qbjls9Qt4HDlcsZ19sqi752akXkAUrwTmZYZkZxTsguRjDy6sRO4dsh2oEgFr8LS4Ypfq/TVF/yoofsWr2CesdbF/b1O87UVk2+nktUbHaapFWRlg3xpenWIA5QX3mdVGcSqclXUYrMXbpYNdaY1KJrQiacRnyY0eOdGSuxCScJMlc4MGbNIpFthD1sRXWRGvrq5Hdz6yyQGzAB03sWrcr1/EI+oQ44caKPb68DhPvAZtWzHgGRsva4BpYkC3ZbMShSMg5rRWSmfecd3Whi2jMdLCKUJqRHH4NncqYAQZM1qL14YZlQ+I2TKFYTZuqslaAqnkoLh+gOC93x9nAsXmKT/sq0+EUGOw6iAu42qKTZNIEIxcebZyH6V/nMl4OFPfPzhv/0G+GoFI= 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: > > /* > > - * XArray of vmap blocks, indexed by address, to quickly find a vmap block > > - * in the free path. Could get rid of this if we change the API to return a > > - * "cookie" from alloc, to be passed to free. But no big deal yet. > > + * In order to fast access to any "vmap_block" associated with a > > + * specific address, we store them into a per-cpu xarray. A hash > > + * function is addr_to_vbq() whereas a key is a vb->va->va_start > > + * value. > > + * > > + * Please note, a vmap_block_queue, which is a per-cpu, is not > > + * serialized by a raw_smp_processor_id() current CPU, instead > > + * it is chosen based on a CPU-index it belongs to, i.e. it is > > + * a hash-table. > > + * > > + * An example: > > + * > > + * CPU_1 CPU_2 CPU_0 > > + * | | | > > + * V V V > > + * 0 10 20 30 40 50 60 > > + * |------|------|------|------|------|------|... > > + * CPU0 CPU1 CPU2 CPU0 CPU1 CPU2 > > + * > > + * - CPU_1 invokes vm_unmap_ram(6), 6 belongs to CPU0 zone, thus > > + * it access: CPU0/INDEX0 -> vmap_blocks -> xa_lock; > > + * > > + * - CPU_2 invokes vm_unmap_ram(11), 11 belongs to CPU1 zone, thus > > + * it access: CPU1/INDEX1 -> vmap_blocks -> xa_lock; > > + * > > + * - CPU_0 invokes vm_unmap_ram(20), 20 belongs to CPU2 zone, thus > > + * it access: CPU2/INDEX2 -> vmap_blocks -> xa_lock. > > */ > > OK so if I understand this correctly, you're overloading the per-CPU > vmap_block_queue array to use as a simple hash based on the address and > relying on the xa_lock() in xa_insert() to serialise in case of contention? > Sorry i missed your question. You correctly understood what i am doing. Basically, we can associate any address with an index in per-cpu-array. Since a CPU pre-allocates a fixed block size, which is a VMAP_BLOCK_SIZE, we can map any address within this block to a certain index or i call it a specific CPU zone it belongs to. If we want fully serialize it we have to allocate a new vmap block in CPU owner zone. According to ASCII picture, for CPU0 it is 0-20, 30-40 addresses. In fact, even though it would be "fully" serialized, in practise id does not give a visible performance. So this is not needed and it has extra drawbacks. -- Uladzislau Rezki