Message ID | 20231212194640.217966-1-sidhartha.kumar@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp7962418vqy; Tue, 12 Dec 2023 11:47:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IFb9ZYALEUzE7ywe+K7c3BbNiEpN9x3HsESVFCsWC/HUn5y24Cg+F1qyyNIjZlKHds6mYtq X-Received: by 2002:a05:6a00:4b0e:b0:6be:25c5:4f74 with SMTP id kq14-20020a056a004b0e00b006be25c54f74mr8280834pfb.13.1702410445742; Tue, 12 Dec 2023 11:47:25 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1702410445; cv=pass; d=google.com; s=arc-20160816; b=boXaiZGzB3Opo2Pg5Y8TcgqLDXv5Q9+qKjWn+P80MPTnEsm9oWbPA1Uqb8llKWnnw6 tW5yCHXLSluVGfjzbONABuuu+Q+HGnnHb29bGC8cUsQ4fPcsYaYxorFGWnSWWw7w/cI+ ucHjdN5Uc3GOF3t7cJaIVj2Fiec1aI2N4zFx4Dv46j76NdDTj/wRZL/sdgjkH3E/5DOa zBoKMKoTSLrx3nJEH5t/WZti3I0KiXAKpiokMLqWQ3ni03PEGAh7EbBCVLixo8e+fhiq BrXD5AaOmWkBooFKegL4qSjK12XrUB2fWwkZWzeS1b50IVvcYafKEBOPzFDyE6hdp74t +vog== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :message-id:date:subject:cc:to:from:dkim-signature:dkim-signature; bh=6UC8hkFahL7aKwhDPSawosYujclYVfTtKyTxfQMfUIU=; fh=B8hmr/q5j3tCmv46TiFW349WPKYIK+b/KkTcg+TQCdo=; b=ZSvgzmWD5RWsajwJdCVtbqQWPG8RHg8NQEmT0SBMrV+BkBkinYlF/26cHg4zOaezVA 2mgjZZtDWAink5s9Nss52q43QuzJuFCE0x/gdcKPF8OY8Q5p1AtYQtEux3xqYiLWfdTt l9iBIi0p5yNAH5t9iC81vJh+1ojmsLJg1yFQiPfAOGq0Xxp2apldH6F/oeA184noXzBn AnZ4QvTOe/k6uemPesTNG19M+4JCqet0gYfdoS5cgxOa6RLPvUbecbwmuSnQbOsckSfW S/84dBVjeTJ1VsA//eTPgwLpXlzKpVFoV++3MDQjCmv/p4IJ0IVNFrVAzItWmZrwSKGG /osg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-11-20 header.b=WOWvBeFy; dkim=pass header.i=@oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=UT38FeiU; arc=pass (i=1 spf=pass spfdomain=oracle.com dkim=pass dkdomain=oracle.com dmarc=pass fromdomain=oracle.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id s14-20020a62e70e000000b006ce7ce0e746si8141696pfh.245.2023.12.12.11.47.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 11:47:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2023-11-20 header.b=WOWvBeFy; dkim=pass header.i=@oracle.onmicrosoft.com header.s=selector2-oracle-onmicrosoft-com header.b=UT38FeiU; arc=pass (i=1 spf=pass spfdomain=oracle.com dkim=pass dkdomain=oracle.com dmarc=pass fromdomain=oracle.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 3A9C48021389; Tue, 12 Dec 2023 11:47:22 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232488AbjLLTrN (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Tue, 12 Dec 2023 14:47:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230181AbjLLTrM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 12 Dec 2023 14:47:12 -0500 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6DCDF9A for <linux-kernel@vger.kernel.org>; Tue, 12 Dec 2023 11:47:18 -0800 (PST) Received: from pps.filterd (m0246630.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3BCDimJO007180; Tue, 12 Dec 2023 19:46:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : content-transfer-encoding : content-type : mime-version; s=corp-2023-11-20; bh=6UC8hkFahL7aKwhDPSawosYujclYVfTtKyTxfQMfUIU=; b=WOWvBeFyFLLTTr6IuxVx234T+1lwjV4IdSWX6JUkpDGxMji0vt+xOf1KMJyolEYgdl5v KkeJtsGb13vPf8KF1OzCXJqklGWpkCWPOX9ZXKFd35xeR/tRtaFAe6Ek0alKVjjyBIwY DPuOLtUuwmp5OohmzVt/ETPPL3kTOfJnnBFSndJiWIdHC/HQaXDcYJWLRRRHeImVezjh Pv3rPSjZKNo7jn/x6o3cGoGs8nWM6MCOwkXdMo8yxfWROiERDoKvzGrFgn75OKK3Jr9i lHMuRd/qLSlAuecQen1BdCsff/ial/y3H3Dt5U88zCv8el7QfKDtssKbkX8QcicSAAcF Sw== Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3uwgn3mtr4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Dec 2023 19:46:48 +0000 Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 3BCIUpJE008298; Tue, 12 Dec 2023 19:46:48 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3uvep732ph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Dec 2023 19:46:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TLQWr4qGVEjl+3LfQCW/fJjTwcbgXq+N7iTcyx4LDtTTwiW03scq3+xV+TkF20KuE61jbG3FwE7x74b9aIVaWOIyW7zvTtIVvO6v26BuICGKdwNWMz1vYrXaK3HqZlxKUATBwsOzCxJkoiLATF9KTAmtJu/XClwkVxiAVIpOWPpejHM/sPyr1Y2G2U9L6rwaek+lbv6Mdmb3mI/tMP42jOiOs/pat6PI49b3mJAVhmvKlsULoigeR7vnvh1l53a7pksnDCPfCGknAz3MMNO90M7UJbvcnaoynUiykX9+GBhS7uFmuVBRKKm86gQQ2HKUfBj5LK+9qIQDf3gZ4J8MGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6UC8hkFahL7aKwhDPSawosYujclYVfTtKyTxfQMfUIU=; b=Sk5icE1YfN/UDIk+cLqVhNXN3mS4cW7QuoGZ0bVQH2aB1XYMtIclxOFt/+146eL4vy48HvLtHhiu+fnEQ0gxuyxptYGX6pv/LTFS4h7qzfF3RhpQWPIaQLsYNU+g+tjGSw/e/qIBKJvMcZshB3uyg0S8y02tplgUjfPxI4WYrq4TAWyoqA3AyvokSXxNh0r69yex9GSSTWE/r7D3JqGnhH+6Qkor/HsNZQGkmwf+UtMO+sbhX+lI+luGn2c/jFSR/ABEK8H1Iu7tAP1se49lBVykEizw0ZtYE2vPCgkUx7rZRS8u19uWbt8ZRkmyAacR/iOqfJXypsM87n/88GgJWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6UC8hkFahL7aKwhDPSawosYujclYVfTtKyTxfQMfUIU=; b=UT38FeiU1RIQV9mG6r1tSzE3n8NnZnvG99pSl9xs3hZv/L60maqnHViUUArBJAA3YUgxQjVgKShfa3KO0ZlOdaLBOfpkEnLo8osaEY8wIjAqm8qNjyUu/wicVfcjyoeegi/n5D3LTOE12Obz76Tz9C/b56A7jMM3W7P5vdxWekM= Received: from CH0PR10MB5113.namprd10.prod.outlook.com (2603:10b6:610:c9::8) by DS7PR10MB5309.namprd10.prod.outlook.com (2603:10b6:5:3a8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7068.36; Tue, 12 Dec 2023 19:46:45 +0000 Received: from CH0PR10MB5113.namprd10.prod.outlook.com ([fe80::7361:23aa:7669:bcce]) by CH0PR10MB5113.namprd10.prod.outlook.com ([fe80::7361:23aa:7669:bcce%7]) with mapi id 15.20.7068.033; Tue, 12 Dec 2023 19:46:45 +0000 From: Sidhartha Kumar <sidhartha.kumar@oracle.com> To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, maple-tree@lists.infradead.org Cc: akpm@linux-foundation.org, willy@infradead.org, liam.howlett@oracle.com, zhangpeng.00@bytedance.com, Sidhartha Kumar <sidhartha.kumar@oracle.com> Subject: [PATCH] maple_tree: do not preallocate nodes for slot stores Date: Tue, 12 Dec 2023 11:46:40 -0800 Message-ID: <20231212194640.217966-1-sidhartha.kumar@oracle.com> X-Mailer: git-send-email 2.42.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR03CA0041.namprd03.prod.outlook.com (2603:10b6:a03:33e::16) To CH0PR10MB5113.namprd10.prod.outlook.com (2603:10b6:610:c9::8) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH0PR10MB5113:EE_|DS7PR10MB5309:EE_ X-MS-Office365-Filtering-Correlation-Id: 8772db88-e214-4dc9-1260-08dbfb4b1275 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Wqsc2cduc5RT/+IwFBFvynnrDWWA1/I25zYp4hlqRzwAyyEwdSC/vMdXiIQjuOwyJjBjQP7pU1W6TYgRkXlZVheOhsDUF6TYo/xNQIRrBjx5rkKTfpDLtWnxZceqfDnbvdfvarqAigs8sgYJM//8C7kUj6sLxop6eQ3GlC312D5IPpQnVzsoPcuxkRUUstElejIREfogdp/pFyZAL1bCLHsvd41vKvMbGJ/nO+iHaSqiAI+sfyhdfsY/DGZ+37UncfTC6KN1yWp+oBmS04933AQCfyZHsl1gmqAdtq9O0zPTZC/n1d2QOEn+x3hfeX0mvU+ovcvE5a4tzgKpBwR4E57rLIi+ECxat8YCTSWjGzqvxY37R8dlh/MrkvTakI/54/nCacOgh2cNFDxQ8KNc1CFOxQI2hQsnIJaQ3+waShymqJHcw576A22JuJUnGuW2dAIg0qAT3pdr+YURPwD+veuYcBewTI5e+kPZAw7rO/M/PiMExh7ZmHA2EO0Wjvd/InhCuAW9JI9O34wqPNms8DlZsKIdI/9oY9dGALTB2xb9/EjnGyMKQctgTWfDuRHu X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH0PR10MB5113.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(346002)(39860400002)(376002)(366004)(396003)(136003)(230922051799003)(451199024)(186009)(1800799012)(64100799003)(316002)(66556008)(66946007)(66476007)(6512007)(41300700001)(6666004)(36756003)(107886003)(2616005)(1076003)(38100700002)(86362001)(6506007)(83380400001)(478600001)(6486002)(2906002)(44832011)(5660300002)(4326008)(8936002)(8676002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: ESkBIl8cLygxlCLquC3SzKqc2FRvQXu0wN4l4v2gZc72byYgeapKvQXBHnfgU1Ve0W6HJZAEOHDj1xww6cVfvTlTPQzDyrwwGRalN7WG4C9o0/6gu0B3nh9ow8wXkJmnOPUFa6DB5UtMNc2e7pS1iz7EQi5FpBIDkTAPvrofx4QYOBUuvD5sEMZjzNu6tDhsPeJLJNKsqEDbW09QFz+679TtlxSemXrylhw+WxZl2Notv0fRh21mFixIMkgGOdh7IU5AOjxDPiMLM6NwEN/mWCw0eR4ujxn/I6m3dcIP2AbFCldE16925gPzzuoZIAOOgpS2CtYePdKspyAFGzX9zzMHH3cyNe33iR2jDQxXf5ai/2HfDgLS27pPcENasfUq++dv+w6XD4Zp/Gek+Scf2SmvSWhY6dfBlbYn9RQK2JiNnys2HjuO+cLYqqhLKkTf2NeCUYUbAFOGB2h8qVNnZpRz3kfhymVfiRraW3gN76gKN8DJ1FJ1Rz2ntOaVdeReDe2OkRQkQzrEq54UTVbDlPF3hF4zewcBaw08YTnlze7tYzjNB8NOndxCAZjdhB0Mz5ibrpBE9tzLOvcpU5TAg8XYXtq2VKi6SX2HeNMmdQpKR03d4LWq+qrDTs+OFCTQ7mQC9fG6lcU2EqqSbD99DSkGQrqSjjaFd/2k4QBJ0izFKOtmEZILwL7HxsPNkyDd3nEdtOjphSbiXKVdsvAA+Xbx1T9JaWknbL0NFolBsZgFJr2FT9ZWMRvOch7gE1gqRG/6MDqpEtJuMmIFj55daCQHw2DwfK3s2KYmBAfl0JCt4gjxRh0vtGp5K1NpEnBp2sdWhE/OzZc+d17l7pnAvw6iIQgQ34EhgGZ7DH6Xh6uE6cvaRSuBcLltn9P6X9AaM6Qb2zB3NSAup4JAepHLOmbk7pG4BauqXef6eQ0rq9LG5yRP6uv36sgEKTl2tvQvYnVved7BIVrc3+9mjHjC1+FQ1MsK57yHadWwB5s32BnpcpJOGkOuiNaGyUf/E1rFCslRKXkFTLDpiIq+94V3bWvLEKTlPbH+29lWFqg3ADF8XZFv88bEHALkkqnbKalauT6K1NGPKcnlFCabCKFuFOIsVb3Di4S4nH1jBuT9nxLOtFOQPQvoh50f/IaH7Yu5QOpVm4qaPOukR7Vv7nYOgIRgkjygFZgKPmnwrh2apojmEqBdivf/Pff+E6QzCWRRMEOSaLFsR2GW+p94ob8+HkEyr4+wnaMqozh/F5ua3xq4g4ewABobJWsEiI37XFnHyKMVHjyc485eeIotaf3v+sjbE5YfMOTTkgBgd2Z/YXNiJyLZTfkaeVTleUi67FEL003HQojrwIny2OHG3+VAOZjrxKG3mbInXdoL3ptPYriznA+Ln7NJSLaLBdJA5VBfKBtu3xrwPtm78RhAw+Kkb8P3Es3yj2Xdx2Zy3cVjh2X3xPfSZ6Hjay3HSr7AU7qDKz1jYnL/p7JfzyEfKnOaAtYj0jrDUgGvtHqL9kJhkT9z4B0C9XOmk9U2bOmwivNgHICvn5eEpq40PliE5nWjJzNHfydm6zzWeOb46FT4dCvEu4Yp7aIjLQXOHGE+WrKPngTLHQPWAB/5i11VriHkP9N4UuxNAb2QVeo3Yr2x/c4= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 5rJcYFIa+4WB1FTSkL2lzb07pJJlx6gdnhxNMneehU9nCNIaeoxrzWr3KJL5E1aMyjIauC+0jYwTivHio4h7MjGKVcPLHdFAyMv05NY9KTQi7oWQcDmuW4wt+MSVn1vnncHNiApkDaQKCtK6OIdf4XenMwXYQHxWfwJimAI+Bj08WsXQC5Zt2Qo8ivSJ57xceTJdX2efEYsyOqemT1JboLy5fNlMZOCP+xL9RUg3dviNDtw/4gQRRCSLhsOEjNZVX8yIruAvyYvJ7QwglAUi6mgbxgIenWRnxCcf5dGXYu9lz3278kEfXffNtAjiUuzwkHCdVQVAAcojmU8HyX9GN+uYoPiZcxgcVdwin6y7I9/XtQdOwE16RbbJtRPOpxzoPatY67xag7OsOw2aASR7qkGCKFd2e6iD1V+U3Nhg9yQZM+ZXumTy964UiKIZJ+ZlZ0x4lQSyglUu0gtQt4ZTx0rd7WjyUbOWWw0XtH9UQ0kgKYb24P3WAXpvUtzbxx8q3sqDkvDC1RtkHfkcxak4g/cgLiiv9c5Knjeh+CiYOexzX6ian7e1oGSHRG3yqGHeI57AU53Qqe4ihvNlmUq6fHQ5IVos4czponF9E7gH0MQRLgWO1MjTE7wVBHWN2q1eqt3aNVIlCBLQ3aqno1M7ba0OfiafIc7Kx9pKs0zO9dYzImPqSBuuNDgzOhO7xyrB83i/Velq4npYwcEGgGooHGb7hCdy7b/5AqxeAVUtf9Gl8YOujWVm6l99T14EDsJGbGtRhMAtKOSOXpacJNBLwEvibeLR2UgZXXwpXdsT9hAKAuOW757C+mp4TNqWn4keKL8S9yuH4B7P4RYVH9MP+oQ37bb7r+NIeKswXWR1snWRsJ4SmTgpQwbtn4ab1M5zer4Ch4p+2S8pJYZL6+pNt7QCSqL5RmMtY+wQDT9OO/Hsf5pZmDOIBha3iuAD9Cqt5c5mfJ6XtgiQsOD0eH8CGGgIhE19CEuhnTw3PsbzZGg= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8772db88-e214-4dc9-1260-08dbfb4b1275 X-MS-Exchange-CrossTenant-AuthSource: CH0PR10MB5113.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2023 19:46:45.5313 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: MhorIutPTZxous8q/jxxKrVAvLx2mq44fnA8OrFwj2WbanrvXkROkpoSt9eu+IGG3OKoJzEXkWHQtlWfKc9rAcnM+4kuSOys/y2Exz+byXY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR10MB5309 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-12_12,2023-12-12_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 phishscore=0 suspectscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2312120151 X-Proofpoint-ORIG-GUID: B8C3UP6f2e5iCrE8-g9P5UWkhwi00Z7q X-Proofpoint-GUID: B8C3UP6f2e5iCrE8-g9P5UWkhwi00Z7q X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Tue, 12 Dec 2023 11:47:22 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785106735230041009 X-GMAIL-MSGID: 1785106735230041009 |
Series |
maple_tree: do not preallocate nodes for slot stores
|
|
Commit Message
Sidhartha Kumar
Dec. 12, 2023, 7:46 p.m. UTC
mas_preallocate() defaults to requesting 1 node for preallocation and then
,depending on the type of store, will update the request variable. There
isn't a check for a slot store type, so slot stores are preallocating the
default 1 node. Slot stores do not require any additional nodes, so add a
check for the slot store case that will bypass node_count_gfp(). Update
the tests to reflect that slot stores do not require allocations.
User visible effects of this bug include increased memory usage from the
unneeded node that was allocated.
Fixes: 0b8bb544b1a7 ("maple_tree: update mas_preallocate() testing")
Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com>
---
This patch passes the maple tree test suite. A seperate patch will be sent
for a 6.6 stable backport as the node_end field was moved from the
ma_wr_state to the ma_state in a recent patch which is not in 6.6.
lib/maple_tree.c | 6 ++++++
tools/testing/radix-tree/maple.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
Comments
* Sidhartha Kumar <sidhartha.kumar@oracle.com> [231212 14:46]: > mas_preallocate() defaults to requesting 1 node for preallocation and then > ,depending on the type of store, will update the request variable. There > isn't a check for a slot store type, so slot stores are preallocating the > default 1 node. Slot stores do not require any additional nodes, so add a > check for the slot store case that will bypass node_count_gfp(). Update > the tests to reflect that slot stores do not require allocations. > > User visible effects of this bug include increased memory usage from the > unneeded node that was allocated. > > Fixes: 0b8bb544b1a7 ("maple_tree: update mas_preallocate() testing") > Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> > --- > This patch passes the maple tree test suite. A seperate patch will be sent > for a 6.6 stable backport as the node_end field was moved from the > ma_wr_state to the ma_state in a recent patch which is not in 6.6. > > > lib/maple_tree.c | 6 ++++++ > tools/testing/radix-tree/maple.c | 2 +- > 2 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/lib/maple_tree.c b/lib/maple_tree.c > index e6954fa75eb5..e4a39beb1018 100644 > --- a/lib/maple_tree.c > +++ b/lib/maple_tree.c > @@ -5475,6 +5475,12 @@ int mas_preallocate(struct ma_state *mas, void *entry, gfp_t gfp) > > mas_wr_end_piv(&wr_mas); > node_size = mas_wr_new_end(&wr_mas); > + > + /* Slot store, does not require additional nodes */ > + if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) > + || (wr_mas.offset_end - mas->offset == 1))) > + return 0; > + > if (node_size >= mt_slots[wr_mas.type]) { > /* Split, worst case for now. */ > request = 1 + mas_mt_height(mas) * 2; > diff --git a/tools/testing/radix-tree/maple.c b/tools/testing/radix-tree/maple.c > index 687886cebd9d..f1caf4bcf937 100644 > --- a/tools/testing/radix-tree/maple.c > +++ b/tools/testing/radix-tree/maple.c > @@ -35545,7 +35545,7 @@ static noinline void __init check_prealloc(struct maple_tree *mt) > MT_BUG_ON(mt, mas_preallocate(&mas, ptr, GFP_KERNEL) != 0); > allocated = mas_allocated(&mas); > height = mas_mt_height(&mas); > - MT_BUG_ON(mt, allocated != 1); > + MT_BUG_ON(mt, allocated != 0); > mas_store_prealloc(&mas, ptr); > MT_BUG_ON(mt, mas_allocated(&mas) != 0); > > -- > 2.42.0 >
On Tue, Dec 12, 2023 at 11:46:40AM -0800, Sidhartha Kumar wrote: > + /* Slot store, does not require additional nodes */ > + if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) > + || (wr_mas.offset_end - mas->offset == 1))) > + return 0; Should we refactor this into a mas_is_slot_store() predicate? A few coding-style problems with it as it's currently written: 1. The indentation on the second line is wrong. It makes the continuation of the condition look like part of the statement. Use extra whitespace to indent. eg: if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) || (wr_mas.offset_end - mas->offset == 1))) return 0; 2. The operator goes last on the line, not at the beginning of the continuation line. ie: if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) || (wr_mas.offset_end - mas->offset == 1))) return 0; 3. You don't need parens around the !mt_in_rcu(mas->tree). There's no ambiguity to solve here: if ((node_size == mas->end) && (!mt_in_rcu(mas->tree) || (wr_mas.offset_end - mas->offset == 1))) return 0; But I'd write it as: if ((node_size == mas->end) && (!mt_in_rcu(mas->tree) || (wr_mas.offset_end - mas->offset == 1))) return 0; because then the whitespace matches how you're supposed to parse the condition, and so the next person to read this code will have an easier time of it.
* Matthew Wilcox <willy@infradead.org> [231212 15:58]: > On Tue, Dec 12, 2023 at 11:46:40AM -0800, Sidhartha Kumar wrote: > > + /* Slot store, does not require additional nodes */ > > + if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) > > + || (wr_mas.offset_end - mas->offset == 1))) > > + return 0; > > Should we refactor this into a mas_is_slot_store() predicate? I'm not sure it's worth it as some of these are deciding factors on how the store is executed so I would expect this to live in a single place, long term. Although, long-term this could be two store types: slot store rcu and slot store so that the check only happens once. > > A few coding-style problems with it as it's currently written: > > 1. The indentation on the second line is wrong. It makes the > continuation of the condition look like part of the statement. Use > extra whitespace to indent. eg: > > if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) > || (wr_mas.offset_end - mas->offset == 1))) > return 0; > > 2. The operator goes last on the line, not at the beginning of the > continuation line. ie: > > if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) || > (wr_mas.offset_end - mas->offset == 1))) > return 0; > > 3. You don't need parens around the !mt_in_rcu(mas->tree). There's > no ambiguity to solve here: > > if ((node_size == mas->end) && (!mt_in_rcu(mas->tree) || > (wr_mas.offset_end - mas->offset == 1))) > return 0; > > But I'd write it as: > > if ((node_size == mas->end) && > (!mt_in_rcu(mas->tree) || (wr_mas.offset_end - mas->offset == 1))) > return 0; > > because then the whitespace matches how you're supposed to parse the > condition, and so the next person to read this code will have an easier > time of it. > > > -- > maple-tree mailing list > maple-tree@lists.infradead.org > https://lists.infradead.org/mailman/listinfo/maple-tree
On 12/12/23 12:57 PM, Matthew Wilcox wrote: > On Tue, Dec 12, 2023 at 11:46:40AM -0800, Sidhartha Kumar wrote: >> + /* Slot store, does not require additional nodes */ >> + if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) >> + || (wr_mas.offset_end - mas->offset == 1))) >> + return 0; > > Should we refactor this into a mas_is_slot_store() predicate? yes, I think we should add helper functions to identify the different type of stores. Thanks for the pointers to code style this is what I think the slot store identifying helper function would look like: static inline bool mas_wr_is_slot_store(struct ma_wr_state *wr_mas) { struct ma_state *mas = wr_mas->mas; unsigned char node_size = mas_wr_new_end(wr_mas); if ((node_size == mas->end) && (!mt_in_rcu(mas->tree) || (wr_mas->offset_end - mas->offset == 1))) return true; return false; } thanks, Sid > A few coding-style problems with it as it's currently written: > > 1. The indentation on the second line is wrong. It makes the > continuation of the condition look like part of the statement. Use > extra whitespace to indent. eg: > > if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) > || (wr_mas.offset_end - mas->offset == 1))) > return 0; > > 2. The operator goes last on the line, not at the beginning of the > continuation line. ie: > > if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) || > (wr_mas.offset_end - mas->offset == 1))) > return 0; > > 3. You don't need parens around the !mt_in_rcu(mas->tree). There's > no ambiguity to solve here: > > if ((node_size == mas->end) && (!mt_in_rcu(mas->tree) || > (wr_mas.offset_end - mas->offset == 1))) > return 0; > > But I'd write it as: > > if ((node_size == mas->end) && > (!mt_in_rcu(mas->tree) || (wr_mas.offset_end - mas->offset == 1))) > return 0; > > because then the whitespace matches how you're supposed to parse the > condition, and so the next person to read this code will have an easier > time of it. >
On Tue, 12 Dec 2023 20:57:48 +0000 Matthew Wilcox <willy@infradead.org> wrote: > On Tue, Dec 12, 2023 at 11:46:40AM -0800, Sidhartha Kumar wrote: > > + /* Slot store, does not require additional nodes */ > > + if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) > > + || (wr_mas.offset_end - mas->offset == 1))) > > + return 0; > > Should we refactor this into a mas_is_slot_store() predicate? > > A few coding-style problems with it as it's currently written: > > 1. The indentation on the second line is wrong. It makes the > continuation of the condition look like part of the statement. Use > extra whitespace to indent. eg: > > if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) > || (wr_mas.offset_end - mas->offset == 1))) > return 0; > > 2. The operator goes last on the line, not at the beginning of the > continuation line. ie: > > if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) || > (wr_mas.offset_end - mas->offset == 1))) > return 0; > > 3. You don't need parens around the !mt_in_rcu(mas->tree). There's > no ambiguity to solve here: > > if ((node_size == mas->end) && (!mt_in_rcu(mas->tree) || > (wr_mas.offset_end - mas->offset == 1))) > return 0; > > But I'd write it as: > > if ((node_size == mas->end) && > (!mt_in_rcu(mas->tree) || (wr_mas.offset_end - mas->offset == 1))) > return 0; > > because then the whitespace matches how you're supposed to parse the > condition, and so the next person to read this code will have an easier > time of it. Yup. But I'd suggest going further: /* Slot store, does not require additional nodes */ if (node_size == mas->end) { /* comment goes here */ if (!mt_in_rcu(mas->tree)) return 0; /* and here too */ if (wr_mas.offset_end - mas->offset == 1) return 0; } ie: create space to add those comments explaining the reason for each test.
diff --git a/lib/maple_tree.c b/lib/maple_tree.c index e6954fa75eb5..e4a39beb1018 100644 --- a/lib/maple_tree.c +++ b/lib/maple_tree.c @@ -5475,6 +5475,12 @@ int mas_preallocate(struct ma_state *mas, void *entry, gfp_t gfp) mas_wr_end_piv(&wr_mas); node_size = mas_wr_new_end(&wr_mas); + + /* Slot store, does not require additional nodes */ + if ((node_size == mas->end) && ((!mt_in_rcu(mas->tree)) + || (wr_mas.offset_end - mas->offset == 1))) + return 0; + if (node_size >= mt_slots[wr_mas.type]) { /* Split, worst case for now. */ request = 1 + mas_mt_height(mas) * 2; diff --git a/tools/testing/radix-tree/maple.c b/tools/testing/radix-tree/maple.c index 687886cebd9d..f1caf4bcf937 100644 --- a/tools/testing/radix-tree/maple.c +++ b/tools/testing/radix-tree/maple.c @@ -35545,7 +35545,7 @@ static noinline void __init check_prealloc(struct maple_tree *mt) MT_BUG_ON(mt, mas_preallocate(&mas, ptr, GFP_KERNEL) != 0); allocated = mas_allocated(&mas); height = mas_mt_height(&mas); - MT_BUG_ON(mt, allocated != 1); + MT_BUG_ON(mt, allocated != 0); mas_store_prealloc(&mas, ptr); MT_BUG_ON(mt, mas_allocated(&mas) != 0);