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 A8A01CD1284 for ; Tue, 2 Apr 2024 16:09:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E67C6B0085; Tue, 2 Apr 2024 12:09:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0973A6B0088; Tue, 2 Apr 2024 12:09:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA0176B0089; Tue, 2 Apr 2024 12:08:59 -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 C795F6B0085 for ; Tue, 2 Apr 2024 12:08:59 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8878FA0971 for ; Tue, 2 Apr 2024 16:08:59 +0000 (UTC) X-FDA: 81965075598.12.A73E327 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf23.hostedemail.com (Postfix) with ESMTP id 6BFDD14000B for ; Tue, 2 Apr 2024 16:08:55 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=buNNX8TQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=nzFbo92d; spf=pass (imf23.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712074135; 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=H2sPx5HpnZNTDX/IqXS+Sby2LHGHtICErN/uS9PWSaU=; b=gkM5YITVr7YTdkyI7Ar6ERXFml6NXAP8G5448j9krTdo5R3W3RCEE82ZXxJVHfSyfhgw1V 3BFf7/3rrZ0NpAQnHoErddQmxMVMamWoDTf245ohGz26XXyU48BTQ7o0JfofGhcfhuvgTn BVtEcrIWarYfPY47AgKGCh8h8Ih7w4A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712074136; a=rsa-sha256; cv=none; b=UzTI4ug/EZAa4X6P2XYwAp2PbD+QfGu8/m/mRDRvQISSZ2tzT6MYPI0KUw/Wgpo/dBGEG0 vf6CqcLO/nEM6GzMI6Apl650dteNooo2Z4e4lvAxNPLzn95vmCcTgvQcgyK9IZ5y3HCrAo IsTuMRmiV1LpQ4c5cR0KW+dqab0F/q4= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=buNNX8TQ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=nzFbo92d; spf=pass (imf23.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [10.150.64.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id A92BD5BF9F; Tue, 2 Apr 2024 16:08:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1712074133; h=from:from:reply-to: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; bh=H2sPx5HpnZNTDX/IqXS+Sby2LHGHtICErN/uS9PWSaU=; b=buNNX8TQQ/QOrvSCFnyeP/jL/LDdv66hn4D1aLLpoA8blKVI9imsfCfmq3h1C+PcU1FB+2 OO4f9ZmqWALj0uB+Dt3Nn8F1gz1+jSfcH05teoDHezptcC/0D05W8koAN24UToBIQCdHdA 1ikTnjTY0YKuoAlx0j5aZOp2EaWgP/U= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1712074133; h=from:from:reply-to: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; bh=H2sPx5HpnZNTDX/IqXS+Sby2LHGHtICErN/uS9PWSaU=; b=nzFbo92dDwq+Z/5d9yXTQ7y2/xqsPhagFlO8Tts56b4eV+dZ1yaqd2BiaCtV4+rRaaTNtp B9DVM/XR1AtM/CAw== Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 8B1E013A90; Tue, 2 Apr 2024 16:08:53 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap2.dmz-prg2.suse.org with ESMTPSA id SQqlIZUtDGarDAAAn2gu4w (envelope-from ); Tue, 02 Apr 2024 16:08:53 +0000 Message-ID: <906fcdfc-f2da-428d-af3d-e1eaf64d1c61@suse.cz> Date: Tue, 2 Apr 2024 18:08:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm/slub: Reduce memory consumption in extreme scenarios Content-Language: en-US To: Chen Jun , linux-kernel@vger.kernel.org, linux-mm@kvack.org, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com Cc: xuqiang36@huawei.com, wangkefeng.wang@huawei.com References: <20240330082335.29710-1-chenjun102@huawei.com> From: Vlastimil Babka In-Reply-To: <20240330082335.29710-1-chenjun102@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 6BFDD14000B X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: nd1y4o89mta7toumkqbcdcppswbtfxfy X-HE-Tag: 1712074135-608108 X-HE-Meta: U2FsdGVkX1+WJc/W1M3HNBpTuRyviVg3CQ/4Pb8LK3it/aN9+gCzMV5pyf3FA2mhKPTdYEuIyOE8hpB+7w8nu2LAdCaJ7ZGJD/GCIABEGNGxVvKfmZJISuA2SyiGykxCxnlAWX4P99js0CsGAYblafv7xCFgSosA4Gb2Npm130x6jjR/3M+8vzsXaQKAOvqD5Uq7mroNSgQJvZIek1L8BDPU3xYZvbtGTvDJE62FzM3tunVndUjezQtmix2il/gMFJn/Yl+HWfz3BlrWcJNmSX01YheEe0zmOrOpjb+osI4JjQk9LyWTkbCrlRX7MugrbKzQbkTYV4QO4pLIT/TsbJFqaAABr9d1c5XaJu3yysLKpRVOwWz+hxnWEKXaUFXjjbZDShLixDo89n898Fjz0XVtH+4PJml6K/un98IgmJ+6SWzpX//NnHQCIXAwRvyHtjkUhpwMWSrwX08Zi20dmGBiQ/DcZ2mlN/M5v09P3nRmXSBtQ/BFcaFi0bO9IIhezpXmMIPuFOhJKhS08VHx0Fo6hrqMTapTZss9yl4doNw1HzLUIrhMeXxErz021R4PQ0Wng6GzZrayPCHBu62xdSG7MZ3r3FqgGvzMokq4683dVo53n/WfGdE754G7em52eYkEUjNiQXrkjmzhjqbX29vTpPDDOHJsDKDjzwe6k6YsvoiAQjgoyFTwrX3kfkyXQKLsy0VW+bqnph5h7qiHZKKjSLSGDCDcVRzdbjmvYGJtV9ADKKyJ4m1D5R02H2DhvhcQjZlgQn0e3tpcDHyyqhkMpNO6MYR2fDP5PgbvFqVOqpzCr3Xpl3hJ+GBfHSE3wKBpo9nwIuMc14yyB7U3ngfAn6R2/jqGD5CkzSD44/ucEfYEWIy03u4Jrh5K1MV2jwtrtj8qpyP52+oe3NCNgTh6DpXbP0kXXWgYV1MOStgstjLqr0rfiQOKoupLT1xQDv/3n93INdNXUjcvFdn vW2HFhsZ DsxGBY2qvzpwRkMKdNKajyERp7KyXPPeqSZNu7ZVx3q2Pv23+TVYhxGn4+Qfd9pvncyw0F069lP4GPXgedUG4Zuh9QFSdaJCvabTilhLcPK4Y/B3utEzUVW4KKtvMtGzK4pF8cdVZ3VLH8uOWGW3QOLxtm0wtaFffjfhDRi6aIYeitjI/42gMf9/3LhdHtYCCwnep/5KkiWYEKmyWXgU+frC6w+jeP91Y0QTzFHRbqVvMesPo//FTJpflZC5XCksbjMuAHJXJSz4L+cr7lxwk6KViViIg8srp0Dgg+yHLUykGyZy4zhAnBpB9fMWEwhZf+AIpTkKv8VXn8NZD04LxlHbGWw51gJMLOY9oA/8jAd+lMN+PSdif9LAa0iRWjQwoNcWi4O6Dy9QxbW0/VTAzS+HM3irLw+DRziFT 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: On 3/30/24 9:23 AM, Chen Jun wrote: > When kmalloc_node() is called without __GFP_THISNODE and the target node > lacks sufficient memory, SLUB allocates a folio from a different node > other than the requested node, instead of taking a partial slab from it. > > However, since the allocated folio does not belong to the requested > node, it is deactivated and added to the partial slab list of the node > it belongs to. > > This behavior can result in excessive memory usage when the requested > node has insufficient memory, as SLUB will repeatedly allocate folios > from other nodes without reusing the previously allocated ones. > > To prevent memory wastage, > when (node != NUMA_NO_NODE) && !(gfpflags & __GFP_THISNODE) is, > 1) try to get a partial slab from target node with GFP_NOWAIT | > __GFP_THISNODE opportunistically. > 2) if 1) failed, try to allocate a new slab from target node with > GFP_NOWAIT | __GFP_THISNODE opportunistically too. > 3) if 2) failed, retry 1) and 2) with orignal gfpflags. > > when node != NUMA_NO_NODE || (gfpflags & __GFP_THISNODE), the behavior > remains unchanged. > > On qemu with 4 numa nodes and each numa has 1G memory. Write a test ko > to call kmalloc_node(196, GFP_KERNEL, 3) for (4 * 1024 + 4) * 1024 times. > > cat /proc/slabinfo shows: > kmalloc-256 4200530 13519712 256 32 2 : tunables.. > > after this patch, > cat /proc/slabinfo shows: > kmalloc-256 4200558 4200768 256 32 2 : tunables.. > > Signed-off-by: Chen Jun > Signed-off-by: Kefeng Wang Slightly reworded and added an unlikely() to one of the tests, and included in slab/for-6.10: https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git/commit/?h=slab/for-6.10/cleanup&id=9198ffbd2b494daae3a67cac1d59c3a2754e64cd Thanks!