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 74DDEC4345F for ; Wed, 17 Apr 2024 18:59:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 020786B009B; Wed, 17 Apr 2024 14:59:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F129E6B009C; Wed, 17 Apr 2024 14:59:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD9EA6B009D; Wed, 17 Apr 2024 14:59:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BE78F6B009B for ; Wed, 17 Apr 2024 14:59:56 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6A9DE120F2A for ; Wed, 17 Apr 2024 18:59:56 +0000 (UTC) X-FDA: 82019938392.05.C7BFA72 Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by imf26.hostedemail.com (Postfix) with ESMTP id 347D7140024 for ; Wed, 17 Apr 2024 18:59:53 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b="mI0r/4up"; spf=pass (imf26.hostedemail.com: domain of jianfeng.w.wang@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=jianfeng.w.wang@oracle.com; dmarc=pass (policy=quarantine) header.from=oracle.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713380394; a=rsa-sha256; cv=none; b=mJzQUJ2HgXLAqrLxiD/EXcfk8645UZ1wmONyuMVlQl8NN3gQ36jHKd3xIF+5g0OLhzyvRs mX29Fg3TrFgSbCqJoZub3xigKuR/+d/Z+76ThYFOlOhN7/P71JJFUdJ1fRkMoflJrhsrIZ 82d+QDIxzRrp/kSEcUXMDJ9JUvWJjvc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b="mI0r/4up"; spf=pass (imf26.hostedemail.com: domain of jianfeng.w.wang@oracle.com designates 205.220.165.32 as permitted sender) smtp.mailfrom=jianfeng.w.wang@oracle.com; dmarc=pass (policy=quarantine) header.from=oracle.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713380394; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=9v67SsM86RHd+fq1rQ349Md4AubcsHfvAyQsA3MVFJM=; b=kNUS5oirIqzg+5N6aRKwJa0L4chDnb4OdZhOuMDWGRh9RzdBXMhf6bmrZMpo5Tz84zxjdT hLKXFfeo+vyBTzt9daDyHOLmGAEjfxzdMS4SQouy/M9KCjZnz+XDQuKnhInqOydf95j2CE vrGyDX1yGjJ5u+08Dp7VVNl3KQ1MTOI= Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 43HHiM9Y005952; Wed, 17 Apr 2024 18:59:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding; s=corp-2023-11-20; bh=9v67SsM86RHd+fq1rQ349Md4AubcsHfvAyQsA3MVFJM=; b=mI0r/4up/xr2QNH8dwUyZLCnu1R4MSJh0AJkbntUZCyCbfBojepeT/Zf+snMF1aHjOze F/ilLS91wus6BeNIstW/DWGkt9tI6a+u5Xvj1z0faMQyVznEqH9oAfeWT+4mgUczC3d8 68H0Cm521xUDy7Q0GKID0TBPqaaeT7A4DdLQJlQKlk+zAUdnb7d9KMO33k47aN8CIflI lPL8XPzFn/kibEDUL5J9V/m4GFeJoIyR4Kc0RMSWDuaEQNa7Y6JWlbJiHZRZKxkmwKL4 J8x/2B0uo43PcksMl63/F5S5QJYgL/cTuCzi8cl1Q7YKTjSBv89plNap6IblYvk1K5HJ ew== Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3xfhxbrjx6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Apr 2024 18:59:48 +0000 Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 43HIZmGN012528; Wed, 17 Apr 2024 18:59:40 GMT Received: from pps.reinject (localhost [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3xgkwhbxj3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Apr 2024 18:59:40 +0000 Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 43HIxdmp026239; Wed, 17 Apr 2024 18:59:39 GMT Received: from jfwang-mac.us.oracle.com (dhcp-10-65-140-165.vpn.oracle.com [10.65.140.165]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTP id 3xgkwhbxhc-1; Wed, 17 Apr 2024 18:59:39 +0000 From: Jianfeng Wang To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: akpm@linux-foundation.org, cl@linux.com, vbabka@suse.cz, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, junxiao.bi@oracle.com Subject: [PATCH v2 0/1] slub: limit number of slabs to scan in count_partial() Date: Wed, 17 Apr 2024 11:59:37 -0700 Message-ID: <20240417185938.5237-1-jianfeng.w.wang@oracle.com> X-Mailer: git-send-email 2.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-04-17_16,2024-04-17_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000 definitions=main-2404170136 X-Proofpoint-ORIG-GUID: OGG2cmFhFCqRvHMNTfKVATP0M2zuI7z7 X-Proofpoint-GUID: OGG2cmFhFCqRvHMNTfKVATP0M2zuI7z7 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 347D7140024 X-Stat-Signature: taoyn3gyybjofd8wh7u9gtu5st9jxaqr X-Rspam-User: X-HE-Tag: 1713380393-71653 X-HE-Meta: U2FsdGVkX19jcBGhaIinsoPcpqtHZmwS9OUywH0mtkB+RAviCg0Ch4kCvVLg66Gx5ZAcSELrsMk7GEVu5E4DowVtYb+N2kr96ous7YuX7EJT0sMV/Lc90EdDaedWVVtzN9u5eSu4Xs4+TdDBXqRFqqT3BpoosR+hqyxoyFbb1ffx/+nVQluQNLOyFvAmwbifzqIStN4X00lu6jxNEvluYQTwr8Ngr+cNwlntfXaV+ea/vGRcw0ttn7vprFpQsXeP2M8MVqNxax8YrhScy3kLMPyiUIobdxBG2krvD5UhaUJ/yrjknbw59nW5kHl/bS3eQeQZdGw/qb2m5lecVNP81MBV29x+PSyNlZIzqzTHM0RWjVW+r+sEPQS70xuheWQ9nJz9MoKfioDjobdp0P4zD2Ro85QaadplVvtyr6HdlqSol+iZqfkvL+KpoIoY6bCPN0rOG4gg6uoC5eNYTn38Vvf5xjrN2nADICuAJUX+z/xSk05AnLgRMFOZqn1i7/oiewpedZ3nmT2oRkdgtLH6Hqv2AaQlJPWJeZcIFwvbQKZWaAgySi4MdxICjmePAHR2gXuecK9fd3m9+bTYC1XtZwAvptzZP/0fZOjWic4I3ANQkmEG5cyyGNxQG9yS9opxMOjUnQRLQwSKweL6V9u7fiY0WFkBefCfN5ViMroTGXUe6PyB95QVlwVm/GNrebCO9FtKjBqgoOnSwss5zoeiY7gaS1NZebSaE5UuX7ica0oq5U4IZuClrHnV7POlG8FygX85Fs9jFS7Iy6K7uc4bwMCqyprFpEicOD0RShHCEYdxpZkwYvKh8qMIulJL3mvepbyBLfIlc9043UERY3otcnvU6YkfANFunVC5UY9+xftlkpHbaX4ow3T5Ala1JGCzv5wLvrnJ0DEqK5SCenTPE1YtOEf+KHR7VyXMoIJpKAjDKHOLkMCc5zXW0T+cASVPKbeTNldpBOfbK5zxVkH dKCSXHgX cpdPo8Lob5SRCPjYH05yXYrlxw4Mw4EoY/tOiHAAm2jazZOWkSGRq9rflINttPEV8qsmG2rB1TqF+MrGNhN/YlXLtzQ0q9gtDWzs09UxuTh1uvCrHB1kC0Lv/HI01K+dbltl0CyF/SM4+FKMQ8mqssB712KvZ2QMqh9ROk4Pia4bkq6uxuIIRf3NsQ6CnsEuf5R90keeQU4+hbejaXWpO5NQVrM31URt6qU9MLZM/ACmdPF7Y5DQaJxmoeU37IxixcvQ6GEygw1eRMb0VkZliyvn9PtgVpV197kSrqxJqvLMqFbOz6ojlns6jD/WWqjS5Uknv 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: List-Subscribe: List-Unsubscribe: This patch fixes a known issue in get_slabinfo() which relies on count_partial() to get the exact count of free objects in a kmem_cache_node's partial list. For some slub caches, their per-node partial list can be extremely long. The current version of count_partial() traverses the partial list to get the exact count of objects while holding the kmem_cache_node's spinlock. This process may take a long time, during which slab allocations are blocked and IRQs are disabled. In production workloads, even NMI watchdog can be triggered due to this matter. Moreover, getting the exact count of objects may not be useful as well: the count may change right after the spinlock is released and re-captured by others. The proposed fix is to limit the number of slabs to scan, and output an approximated object count for a long partial list. The v1 patch counts N slabs from the list's head and then uses it to approximate the total object count in the list. As suggested by Vlastimil, an alternative method, i.e., counting N/2 from both the list's head and tail, produces a more accurate approximation after the partial list is sorted by kmem_cache_shrink(). --- Changes since v1 [1] - Update the approximation method by counting from the list's head and tail - Cap the approximation by the total object count - Update the commit message to add benchmark results and explain the choice [1] https://lore.kernel.org/linux-mm/20240411164023.99368-1-jianfeng.w.wang@oracle.com/ Thanks, --Jianfeng Jianfeng Wang (1): slub: limit number of slabs to scan in count_partial() mm/slub.c | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) -- 2.42.1