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 5469EC25B78 for ; Tue, 4 Jun 2024 21:00:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D2FF86B008C; Tue, 4 Jun 2024 17:00:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CDEAD6B0092; Tue, 4 Jun 2024 17:00:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA5336B0093; Tue, 4 Jun 2024 17:00:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9D07B6B008C for ; Tue, 4 Jun 2024 17:00:34 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 184F31C1D55 for ; Tue, 4 Jun 2024 21:00:34 +0000 (UTC) X-FDA: 82194424788.26.DDD656F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id 5381840013 for ; Tue, 4 Jun 2024 21:00:32 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=X6SZkmnf; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of vbabka@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=vbabka@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717534832; 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=0qosb/qbd54B2qENhP6wM3+IIZ1VjJgmIxFMwOd2F0g=; b=7fD48+/oXTAsHtETTU1XcurTY9RU3MH5duITx+osSH+ZjanQfaRv9VxwVf3XE64REs8Ksc 2MhnZa75PaFNRFyokhyfrlCuAOQg2ekZd7amDH17M1P+sQYuFkcIEqesFzDfretWG5Or37 GmMqQ1VkyRGyl2hIUuVaxG+BWv4KGSA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=X6SZkmnf; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of vbabka@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=vbabka@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717534832; a=rsa-sha256; cv=none; b=Y6pLB53f+ZuwxXnfzlcTfriCKTXsTtGFnEjVTbhnFZXSvwYxp2/fSRxnneVSCcQ2rQhC7X WjoqIBcRQtovL0evh9JvTPr3QaueJSMYmG//V3tJYpBpdwFQ5mxInOcNHGUQWjo4v6vvFe eXuARGq9iqYdUqOfHXjzK+AgCHoJE4Q= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 723F2614E1; Tue, 4 Jun 2024 21:00:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02085C2BBFC; Tue, 4 Jun 2024 21:00:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717534831; bh=y2QXvMKu+toawTwirI1umsvW2EK6ZKNHpsp7PVAKxNs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=X6SZkmnfZNgOG3Y3weWs3ETi/VO+/8FSLGaEoUwWuqLXTY+QWWASCFl7GDG8ZuDYY WUGo/nq/1yyD6/1E9RZwQ0gQNaw7wvYTOxdctLnUUvGc8e8UBk70GAHvtAtllUogFZ 8w8QyXtLYb6/U3wSGLRWhHL6h6bXtvRpsKtHn6uAZTsmwIBmjp3dJqYF0ntVRjq5OP Q0PXMqPXX4Bm3KwVcHMW9SIf4aL+HFzr/sMZIy0N4mn43ZTCOpKn8j3qdcbmOH25eJ QfIKgwYun7772uIhfxPV5HsYtwifcSZ6P8JqKO8hMiS6sGhhFnQkOGCJ0uDa0U8ZJJ UdLaDsEIykCJg== Message-ID: Date: Tue, 4 Jun 2024 23:00:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: kswapd0: page allocation failure: order:0, mode:0x820(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0 (Kernel v6.5.9, 32bit ppc) Content-Language: en-US To: Yosry Ahmed , Yu Zhao Cc: Erhard Furtner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Johannes Weiner , Nhat Pham , Chengming Zhou , Sergey Senozhatsky , Minchan Kim References: <20240508202111.768b7a4d@yea> <20240515224524.1c8befbe@yea> <20240602200332.3e531ff1@yea> <20240604001304.5420284f@yea> <20240604134458.3ae4396a@yea> From: "Vlastimil Babka (SUSE)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 5381840013 X-Stat-Signature: mrp6d5gutu68fanxn5zdfhibpn7dqeoy X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1717534832-687344 X-HE-Meta: U2FsdGVkX1/RamV0mL6zWxIGCYIgp7bErvRKwPlMCM6Foxz0RKqgKBVNcw/EP9nCgl6ztGttVffmhNv2C+XEI56GHWusCy7LV9E2goZbU0C2edRxe+nWGoo6gWaxOxTtKai7GYOu5FnnGFU67RYWrNXwwLC0umLxPg9l8N7Grn3ZoGKKCgVg05BcmELiLWUxmb8eJmK9fCHQXF87SahOkULGbCdOrNAkzFo74gfjV+WHotETBDJn+74SqeOTh6U08Z0qsHx/tCLwgdQj6z25Azt1wiSEdDFcO+euowjwhjSB7CwpqfZusY6NmZcuFlPxwX6a57MbCxBDMWU152FCpV01ZmRRK7XU7qT+lGuP+imDEgC5Eq4Gj2SqY/PLRTpPDiaxv3y4mtzxc9ORzZjMUAU5k5MaaSM4wLvrJ+biNWSP60DgcoWBjvo6EMpMagFz1uM7/J0sz0bSdMMl+7qbfHXdzhGWaLkjRMJ62CSg55lG/Y0fOOuUZKPjzDZfV/JXbUHmqrznhLKjL4MMLlYLGvLVgW3ZF/2TIwaIDcssEcbH73r6AH/iM3UecX7dLtn9Ac29EGejKwdD9a7b2nVy9NizL9UA+5H160hZfN0AnwlEh2GKqFQz7IidkDb4WFnGFHOMug/0XwKeX60opliZaMhTCl7wwuxhQLklT612GKDb/0csTkeIX4YQSQDAjU5Lvu0ZtrUXetQnj29U0fA745MQi8YfimrbymC3Zu2YCgGdfvg0eq3Cp7LboaVsjMts3xpw+BWHLsKAOdn9zwEKR/+yGdQRvCELLn6I6NEe4a6Aa2VFsYWu340BF8cu+pt5YCkNGYD5vlywlLMXEwPEW/IGQ7mEyGfXsoU2BUBnl508xUkwJ5YQZ/65jgen7hw3rxWa8tAGv8E4n0Z8DZ+iZtPRk2409vMfdI65HDrqhC1tHEV3qSEDVJkVInev/mDwTfagIXFD6YX2QuRfgEN AsNJ3so6 hiyzSwD9egEnOetZyDQCIrG+UtOr4Ueu6QkJBRPbNpSZrjGYbK3oxj0bLLe/WgFElbLJk1sQsM1oM66xOleKHLU2D5rTEvczN0Xgj23JBlsW58j/fonozkGSthAOw0lVsRZYhgXelpFS6humiiwQRm0Er8XgYAcb2C29tc8XXJAuqIFEUPMloENM/cUAmP7Mig1Fg+7BF6xrqWnivSxMvkFi7UW90k4L0GHqEqh6cik9hWi1AyIaLcNUU1lP6DQ5KpUuc8ctg6bYVtX+eR3lk6vBTLbnGC4ALj9XtsmAv2lA6Mwqz//9A6CvuduXxh9UrSOPf 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 6/4/24 8:01 PM, Yosry Ahmed wrote: > On Tue, Jun 4, 2024 at 10:54 AM Yu Zhao wrote: >> There was a lot of user memory in the DMA zone. So at a point the >> highmem zone was full and allocation fallback happened. >> >> The problem with zone fallback is that recent allocations go into >> lower zones, meaning they are further back on the LRU list. This >> applies to both user memory and zsmalloc memory -- the latter has a >> writeback LRU. On top of this, neither the zswap shrinker nor the >> zsmalloc shrinker (compaction) is zone aware. So page reclaim might >> have trouble hitting the right target zone. > > I see what you mean. In this case, yeah I think the internal > fragmentation in the zsmalloc pools may be the reason behind the > problem. > > How many CPUs does this machine have? I am wondering if 32 can be an > overkill for small machines, perhaps the number of pools should be > max(nr_cpus, 32)? > > Alternatively, the number of pools should scale with the memory size > in some way, such that we only increase fragmentation when it's > tolerable. Sounds like a good idea to me, maybe a combination of both. No point in trying to scale if there's no benefit and only downside of more memory consumption.