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 AB06AC636CC for ; Sun, 5 Feb 2023 03:56:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C34646B0072; Sat, 4 Feb 2023 22:55:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BE4FF6B0073; Sat, 4 Feb 2023 22:55:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAC196B0074; Sat, 4 Feb 2023 22:55:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 977C16B0072 for ; Sat, 4 Feb 2023 22:55:59 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 613161409F6 for ; Sun, 5 Feb 2023 03:55:59 +0000 (UTC) X-FDA: 80431874838.29.6F48B71 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf29.hostedemail.com (Postfix) with ESMTP id 8CBF1120006 for ; Sun, 5 Feb 2023 03:55:57 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=XAEacJ2O; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675569357; 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=XNB7l69G5EVamMMwD0y1T6jxH8qZN4tcziNc44xXMCQ=; b=yjebEAydyOZTt1xjeBqLZ6r49k6QwQNP0ack0cVYPc6GGMxUUR7Y4u6vxjuPkhFa3MH5n1 x6WkHDpvAU0desJ6n+HIg1Y8jmpDV6jtPw3MOK0PM9WXGtkuCOnANPiXsR5NWkh9hKolSa uLkbavQPJXUloc0OWfGG+0r/klOKGfs= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=XAEacJ2O; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675569357; a=rsa-sha256; cv=none; b=5hdsVseOMDlScUzudXeYyihmoi8qmsvGXRHurNateotI64RCvTCry8haf5UKEllyv7svhG kWlDWee7gJCYbcwsMkoA6nQ8UlPI++PS6TwQipeKtweKB2FM42iQPPpz4iSercdzBnUesP kinhGLWpGB8Hr0CfzK52H4+dYpHLg5c= Received: by mail-qt1-f178.google.com with SMTP id z5so9700232qtn.8 for ; Sat, 04 Feb 2023 19:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XNB7l69G5EVamMMwD0y1T6jxH8qZN4tcziNc44xXMCQ=; b=XAEacJ2On/XjzYCIN7d/BXM4IDi7UX11lCS0M+fk3v0oVOu8FPTFeWHzQ0pk6iQMkq CU26rqpkywfaaf01hw4xlng4lk3oZkfBEyEi5zhUWuDDD/YRBflmNztFeWXS0DPRqfqn YFxaA/YfFmgGxdh5P7rsPB32yVUZ4u4K4aHBeVfT+pwUNybXFPesiQv7kYR77qdfIZG4 s6BoRPzMdVSC2Iy10izwvAbhHF1VpuyHoIl8PgZeThvjgItClrGCEW4+9OcHbH9xev2I bgB3keeYjOsZg11SqB/uiI7OBLj14gm++BXiLm51PHkBnp9t44rhJ0XHxiVSr0fCeB0H B8WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XNB7l69G5EVamMMwD0y1T6jxH8qZN4tcziNc44xXMCQ=; b=3xLhrtxUxMrk8UZKZo2BMc3eKVVVWIkyWwVDX1x53X+tPrfdRG+H1WIumlvAH7s0yS ZK23o0/weId5YqSine1r2bc+A0CohZXFSSHnzexEJG5klQmcKTNZyWf2kfJZi/jPM1s1 bzkX0HEGaGFsDem0llW0cm0URX6KlhJ9rYdvJpZJInDIs75AeFoEbC642yLjSz7izWsk 3x42PVNUNpVR8XOVZ55+j94HRXIlsZKRqo6x5kSgZyUuUpFKwdO1vKA+ctwMKCqOMudK kTZd7HljARQmDO6PInXs8n9kLE2BOtpZDDS62PQKE5kfSLTrgFWZxCgSaRnr4/TZGjr/ ft+A== X-Gm-Message-State: AO0yUKWuDUzLuCW+aP2UK+KiZ3bLmRFHPnmnJKSwKOc97QNBoEtNk3oa ZUzuGKVvYViC/Ayq+RkcpJfh2U3UOnKtIzh+9yk= X-Google-Smtp-Source: AK7set/IL926C9dc4nDRWsDCvzI/WMJNRgkMW8R5SV33JrNMeAh5vKZJReFp93RP25S5KXBq3G98wlyNvnNwwvh9Xyg= X-Received: by 2002:ac8:5fd2:0:b0:3b9:b148:b734 with SMTP id k18-20020ac85fd2000000b003b9b148b734mr1893028qta.65.1675569356625; Sat, 04 Feb 2023 19:55:56 -0800 (PST) MIME-Version: 1.0 References: <20230202014158.19616-1-laoar.shao@gmail.com> <20230202014158.19616-8-laoar.shao@gmail.com> <63ddbc69ef50f_6bb1520813@john.notmuch> In-Reply-To: <63ddbc69ef50f_6bb1520813@john.notmuch> From: Yafang Shao Date: Sun, 5 Feb 2023 11:55:20 +0800 Message-ID: Subject: Re: [PATCH bpf-next 7/7] bpf: hashtab memory usage To: John Fastabend Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, kafai@fb.com, songliubraving@fb.com, yhs@fb.com, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, tj@kernel.org, dennis@kernel.org, cl@linux.com, akpm@linux-foundation.org, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, vbabka@suse.cz, urezki@gmail.com, linux-mm@kvack.org, bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8CBF1120006 X-Stat-Signature: dbf7sws4du9oeb9pxnhabsbs18rbu9f5 X-HE-Tag: 1675569357-990040 X-HE-Meta: U2FsdGVkX18e6HmOY0oGi5zIvdNgbMRtzZ5b98FMvg4ZBzC0xBeXCIZWCEDWk6PZKHeCZn0ujtKm0kKT+gGJ5GCpI6mqv8uj0SyRWKGyVBh6tLD7woYlpspfvQQRl3+PAotGSZZssUnkrQ5Q+097loEZ2AYY0QXAeZUwr2MDfuGHYa6bc2As9eNHV6OuALnMfY1URiqny9II96ouWgPg3ezPN+afBvr6eqqeCXNJc2HS5NClP28mn30ZWIrg+3LVdBk/5fYFwRLNFGL6cng5httctfc7eDqXsjQTWbIFOvaIHObPC7SLDsTmAhUODKH1kOYn11u4LY/5tymPJOfUNgsbfPKoHKu0qkh+7kC31L+GaZGSnUelvov2kLui4WN4NBm81db232qQga+jK4Eri+VC630QwxKwdfK8F9Iemnq5Jzqxe9TJfHfZSV4xh3IGt25sNJM4tmOU45SqaQk4lwKxbqwbVqgpkQ/PSwZVpkSl5C59kJeS016bDvTTJ1jrKC77a0+jo6DnB/kY4NVYWK2iUbA27+B4aelMz1TPNx0aoSplt1c3V2vPBvYUhPjjGJQfqHTFByjJCMDwpYGPMohqL0gfAd/XYHEFHwUQFtMoUoL9Bst9EGZlmDdM20H3MiSB9utCLnHhVkbDQDfEM3HBaUAtGMX82qQxJfg75cNl2y7WUGgeo1dHR34iHGND433G5LtXDXYkwoIU1VYb+yzIYJ90nreGVlJ2qZboUTFqPygyl1fjovo9ndZ3cqjw1WqvHBb1O3jrdGVwbaXKC83Bib+tLTz0atvmH6MDegY5+SSmRJunIPE5oBTbvULC1g2Fbz5Owv+N+4h6MkizplR3qH6y5jTcNkpd2H3t2PKX5FP5ZlKpelYzTfmTCpu4RgpZUGZjBUsExiSDwMrI+lt+rGYN61nx9KL5IH1AA1Zk5ptA3VKjgMCGQ43XruZbzzYVAKP0JyiCQGh2389 HDtEqr3P Uwmq41UYjCa0p36Xls1QR4359e22ssZgtNaWo/5Jdf8fyk29akEpOZoECqsSQz6cSLnjESGts3/oO2NkLyojNGLZAOTNRlZylm3Bi+EVDbGdB2Ou8u4UD/pXpGeWyp901XPWBSRxZMHdQBRWDzOBd8D64hh6DCIIEKR2NPB9TMEv/yupKKmQ/6H7OH96EEpuUt+Kjip70IabE5637edju/mcT5J3YYdY01NW3Fbq1g0ZwO94bwqSCe6QS5qHpCeXCti7I4MD7eZbR9GLB+cOiXmAEfCeUqT12TkJ+KcTJnKzNNwnFFpb/agEYU+91omqUPQi37h+zyrX8Dl+cBBn7WI9AhKeMTx56dJaz+ZD2WvRzIjLakP9GiraAi6ZRCQifCMV2FtBxaNF6LewBQOUXemF6EnMyFc2JlJIK8q1nhW7Flre/juotouCbM1v96s7sSQhENgG+zKcVbf4SsG9hILF3EbSlIFpZ/8tf6aZnN/eCsFpAhQHJpK3InA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001974, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Feb 4, 2023 at 10:01 AM John Fastabend w= rote: > > Yafang Shao wrote: > > Get htab memory usage from the htab pointers we have allocated. Some > > small pointers are ignored as their size are quite small compared with > > the total size. > > > > The result as follows, > > - before this change > > 1: hash name count_map flags 0x0 <<<< prealloc > > key 16B value 24B max_entries 1048576 memlock 41943040B > > 2: hash name count_map flags 0x1 <<<< non prealloc, fully set > > key 16B value 24B max_entries 1048576 memlock 41943040B > > 3: hash name count_map flags 0x1 <<<< non prealloc, non set > > key 16B value 24B max_entries 1048576 memlock 41943040B > > > > The memlock is always a fixed number whatever it is preallocated or > > not, and whatever the allocated elements number is. > > > > - after this change > > 1: hash name count_map flags 0x0 <<<< prealloc > > key 16B value 24B max_entries 1048576 memlock 109064464B > > 2: hash name count_map flags 0x1 <<<< non prealloc, fully set > > key 16B value 24B max_entries 1048576 memlock 117464320B > > 3: hash name count_map flags 0x1 <<<< non prealloc, non set > > key 16B value 24B max_entries 1048576 memlock 16797952B > > > > The memlock now is hashtab actually allocated. > > > > At worst, the difference can be 10x, for example, > > - before this change > > 4: hash name count_map flags 0x0 > > key 4B value 4B max_entries 1048576 memlock 8388608B > > > > - after this change > > 4: hash name count_map flags 0x0 > > key 4B value 4B max_entries 1048576 memlock 83898640B > > > > This walks the entire map and buckets to get the size? Inside a > rcu critical section as well :/ it seems. > No, it doesn't walk the entire map and buckets, but just gets one random element. So it won't be a problem to do it inside a rcu critical section. > What am I missing, if you know how many elements are added (which > you can track on map updates) how come we can't just calculate the > memory size directly from this? > It is less accurate and hard to understand. Take non-preallocated percpu hashtab for example, The size can be calculated as follows, key_size =3D round_up(htab->map.key_size, 8)=EF=BC=9B value_size =3D round_up(htab->map.value_size, 8); pcpu_meta_size =3D sizeof(struct llist_node) + sizeof(void *); usage =3D ((value_size * num_possible_cpus() +\ pcpu_meta_size + key_size) * max_entries That is quite unfriendly to the newbies, and may be error-prone. Furthermore, it is less accurate because there is underlying memory allocation in the MM subsystem. Now we can get a more accurate usage with little overhead. Why not do it? --=20 Regards Yafang