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 40F8FEE14D3 for ; Wed, 6 Sep 2023 19:16:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E9BE8D0007; Wed, 6 Sep 2023 15:16:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99A208D0005; Wed, 6 Sep 2023 15:16:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83B008D0007; Wed, 6 Sep 2023 15:16:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 725128D0005 for ; Wed, 6 Sep 2023 15:16:32 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 34748A0EA9 for ; Wed, 6 Sep 2023 19:16:32 +0000 (UTC) X-FDA: 81207129024.12.675C4F1 Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf16.hostedemail.com (Postfix) with ESMTP id 3F5D4180021 for ; Wed, 6 Sep 2023 19:16:30 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=bFVRMgbN; spf=pass (imf16.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.46 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=1694027790; 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=1isv7HeloaiAJI2agIZVc+2h9VVYfJCr8q7rsrwe9zI=; b=nQN9Y7a72U8IF6tp56RzcZH90RcGaZ8l49htxUtjHrEt6DbnSRuMTzAO1/DECqS8HihC72 5DXmpMDWoZYeuRSXZKKOte3+Wyk6W5S5GXz77wm6GiAFaHKyPpajes5vrNN1mui/THoWjj Yr4GnE0IRxbSSYCVvs85NQK8DWq86og= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694027790; a=rsa-sha256; cv=none; b=2NekHxEnWj4E0WGdkDOPtHLM/ITwPdyy4ROmdsJvuFIDyVW1e9mHicvl9+A4ojsSoIED4z /PlVGjQ7m2L/PZYDckvJ2dYZq2NbQqhWd2eKgzYFk9PNJd8GbCpqNiQ95bpK89JWY2OV0X LUeF0CruuRO9+tkOJBqkA54JgYdXAEE= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=bFVRMgbN; spf=pass (imf16.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-500913779f5so199036e87.2 for ; Wed, 06 Sep 2023 12:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694027788; x=1694632588; darn=kvack.org; 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=1isv7HeloaiAJI2agIZVc+2h9VVYfJCr8q7rsrwe9zI=; b=bFVRMgbNSGbEmx+WhJacl3g5yqmfTRuLcjBIhZJH8ob0MOAhbJ9q+mKigyQr1FJD8p CifLYKV1NyWYBIGoORwncyzWIgI62KHAmJPNzJco0sOq+MBy0CVlC/rVHung6gF4SEkW WEnBrmlZFhxqO5hJ+dp4f7r1MHvCOntE9fJslWxgMl8UXwLBOi17Ic0icyZXrJaK03y7 NfXGBJVrZwmH0d9SqMqBHLXb01NFPdGdqEMIIcVsXWrDm72J4wj/Kr8GeG7nK2IPkjWs gICP5Fig27SoY9n3gi362e0ADAqs4bAEH/WsiNwfg/JcoD6nZNLtkouXEl8mSNKu9ipk W2Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694027788; x=1694632588; 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=1isv7HeloaiAJI2agIZVc+2h9VVYfJCr8q7rsrwe9zI=; b=Ju/2W+a7oGKuNtlbglH9HE6gwRHdpFc4aizkVuBfwHXvL5yOrIKEQcHixX/0PVwmLs u5/GVp+s1fPL7cwkYanri9BKWrsWGCPIfPIZqi5BoKQTDyWS6OUxd3xyyHyrH7gg1QYx 2+2UABPBJA6wkoFLwYzkQqNgdRTKSVdxf0++DF4sT1HVapGVw6OitmRqRU5Jf6Qv3GDk HDII70GUxpOQC4EZPpAdBVfQ7l9OEs1iDhEsNQ3tUWO1IYoDZmVXCH6xEESenHnjjZ+V zh6m5fW2Wp5twEMroORXG+E5A0j9YtcS6b1UepDwckI8aT2E5+nhdM3ch4q2c/4gEqY/ u5DQ== X-Gm-Message-State: AOJu0Ywq0lNbRePt2eosiAgtAT9zqiggdK5zH34Na+mgOFd4jbI70P0t zdgkaCpPjkfxdjqlnnRDB58= X-Google-Smtp-Source: AGHT+IGJGdoq1Q/AEvIuNHd2zyEEzGW6CpNIadi/V/3BHoyrQr0zByFy4AAAENTqzjvspx81/JbcKg== X-Received: by 2002:a05:6512:104d:b0:500:95f7:c418 with SMTP id c13-20020a056512104d00b0050095f7c418mr3890196lfb.39.1694027788110; Wed, 06 Sep 2023 12:16:28 -0700 (PDT) Received: from pc636 ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id b12-20020ac2410c000000b004fe8593b67fsm2838050lfi.107.2023.09.06.12.16.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Sep 2023 12:16:27 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 6 Sep 2023 21:16:25 +0200 To: Baoquan He Cc: "Uladzislau Rezki (Sony)" , linux-mm@kvack.org, Andrew Morton , LKML , Lorenzo Stoakes , Christoph Hellwig , Matthew Wilcox , "Liam R . Howlett" , Dave Chinner , "Paul E . McKenney" , Joel Fernandes , Oleksiy Avramchenko Subject: Re: [PATCH v2 6/9] mm: vmalloc: Offload free_vmap_area_lock lock Message-ID: References: <20230829081142.3619-1-urezki@gmail.com> <20230829081142.3619-7-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 3F5D4180021 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: dp5cko5xdi7sekaf7ecjrawzaqfeuxu7 X-HE-Tag: 1694027790-611116 X-HE-Meta: U2FsdGVkX19xdwPXpWltH+YJ0RA+irTcU4OIUad9YspZgogf9AppK1N3B9Xmv2UQHbGjkpVmdoPRQdXMUAXSo5JiLrSsWF5gs96TxUhd4tO+aOsT/L+4oVJwLLy1CzSNSJRF0Uv1b+TFRmQYk3neIkaf2WXSElmOPL17PA/OwT7nZylaA3Yt3Jjm9glGNZ7JFaQNZhGg1h1kcbnhN53j1Kom8f/bKOMvXtBKfET1yW4rVRHdX7E1wKXz/szCj6+9/+Sy/eDTZbKyzUu5KQj5dkNeuWOkYCwHcKSUwEyTvIpsjfv/xoKdDpoY7CuYRnTDpQ97wEV+imSR2VuDf+GV2V8vWkz9p659i0Pe/zdzFZI1ybOrqwZMBHfWALVaiDAh3k12o+NkEq+l+tbc8YrQ1ChUvVkYNq+7QWzQtPnPPqwWX5wD1UPPKTx7gE49L8VAzqA/dcmotkC1sqGHdsgsRAPg/bp+0ii8f+hLkf5cKDAzGHU3hAfkkmVnp32vIfzjcyVxm7LTK3s2PpmnfdFKES80VymyHF0tMZcsKZ5eSNRkSGAOQaYJGvcWuNI6yAXCLEduPvYUXlJSUG2Ng4jh1LC7L1d4/m++We3l/SWVxGWK1IevsJ7vZq3Oc+axoFy8e6Bs4RRPLOecCCJp5a9yn7A/yRtL6hDHbAzZvH0cWJE7NOxvP4GTyUDwQHV3KyZTLMR5IwWTzwatuk56zSoNYTTr/gPl3QmJisgqidcapPDpxr03pdYNbcCPiXJrFMBXjvRdJRFcyoZmr8OupcU/cNtTZvx4l8pBaT2IUH8vyhLKLJ6hDG/Ahec3PkUVY6SBLqTJGUkLZLIWQOn0f3r3E0qcWioTXxNLOShk11FMkjum26zZthBk7Fp+Y5ZeQrvfd9v6Vx/KCehhb2o8ki9R02RrYlK0iX8iAnU0oYAHx3lCGaMNYGBC2SCQ1XXJsB8yz8LEhYS59jk5pCOa7Vq eEMjnd4x oXee9HZRGQ8pjN+OXyvhO4rQJrllhQYuqXK5uHPt7fKDW55M3L6TU4LF/FCfrF+FQ0QuYeNytSw+bntWuYpSlce8v2F9NE0HYaPnF5J24GHeSAqZNdlNm+EmVZ4JC3YrCHyuTVnrNBlmk10B8gT2AMnxzEM/viF2W+H6Atax/F9AAJNH1fTasIdAASJj+ZFpvHg8VydF24/RXh3XpHWIH/6KrjWAegTEzgsDlgDMD6MWtPky36cR66FOWeF4XGbx0/GnvKxmODFNoxFFpdBGbVr0ekJ2Ez0dA7E/l2a7jIPqJdfAPERhmJszx7KPXktZMxGFK8vu7Y3RNoYvgC32eI0Xic10RUaokaN/LzUpbdBzbzmPzl8TDH03hzynVewn8it4QbY/npAy5DCZvr0UqOEWtozWSX2OKd1mWhvwmlIZHNVof1Bgv7uVdAfYRfcsu8o62obWMrA/QfjrPJNDcr6L45KTRKPsaObp3 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: > > static void free_vmap_area(struct vmap_area *va) > > { > > struct vmap_node *vn = addr_to_node(va->va_start); > > + int vn_id = decode_vn_id(va->flags); > > > > /* > > * Remove from the busy tree/list. > > @@ -1594,12 +1629,19 @@ static void free_vmap_area(struct vmap_area *va) > > unlink_va(va, &vn->busy.root); > > spin_unlock(&vn->busy.lock); > > > > - /* > > - * Insert/Merge it back to the free tree/list. > > - */ > > - spin_lock(&free_vmap_area_lock); > > - merge_or_add_vmap_area_augment(va, &free_vmap_area_root, &free_vmap_area_list); > > - spin_unlock(&free_vmap_area_lock); > > + if (vn_id >= 0) { > > In alloc_vmap_area(), the vn_id is encoded into va->flags. When > allocation failed, the vn_id = 0. Here should we change to check 'if > (vn_id > 0)' becasue the vn_id == 0 means no available vn_id encoded > into. And I do not get how we treat the case vn_id truly is 0. > > va->flags = (addr != vend) ? encode_vn_id(vn_id) : 0; > Yes, vn_id always >= 0, so it is positive since it is an index. We encode a vn_id as vn_id + 1. For example if it is zero we write 1. If not node allocation path or an error zero is written. Decoding is done as: zero - 1 = -1, so it is negative value, i.e. decode_vn_id() function returns -1. -- Uladzislau Rezki