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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A7AD7C25B75 for ; Thu, 6 Jun 2024 06:07:38 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=iwKwqsfj; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Vvv4m56kMz3cZC for ; Thu, 6 Jun 2024 16:07:36 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=iwKwqsfj; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linux.dev (client-ip=91.218.175.178; helo=out-178.mta0.migadu.com; envelope-from=chengming.zhou@linux.dev; receiver=lists.ozlabs.org) X-Greylist: delayed 608 seconds by postgrey-1.37 at boromir; Thu, 06 Jun 2024 16:06:52 AEST Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Vvv3w3tL1z3cWm for ; Thu, 6 Jun 2024 16:06:50 +1000 (AEST) X-Envelope-To: senozhatsky@chromium.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1717653378; h=from:from: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; bh=+8Z5XmpUE3zx1Y8cy7cbU/CoYCfPRTM2B2i5o3MFz18=; b=iwKwqsfjoGXVgQe/po1O8i4bOhN+NhoK5vwBxCPBRqhvuJO6LC62WtY9E5l6kKozckGXAN ENQD0kw1r5cy9frpP4esDYHVVJkYEgPMeRbsQqoP8S+NpNI4S+mRQgCBad5qPF4uRF7Akg A+vmKupx/CjWu2gH98ucZkabpnMTcQs= X-Envelope-To: yosryahmed@google.com X-Envelope-To: erhard_f@mailbox.org X-Envelope-To: yuzhao@google.com X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: linuxppc-dev@lists.ozlabs.org X-Envelope-To: hannes@cmpxchg.org X-Envelope-To: nphamcs@gmail.com X-Envelope-To: minchan@kernel.org X-Envelope-To: vbabka@kernel.org Message-ID: Date: Thu, 6 Jun 2024 13:55:50 +0800 MIME-Version: 1.0 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: Sergey Senozhatsky References: <20240604231019.18e2f373@yea> <20240606010431.2b33318c@yea> <20240606043156.GC11718@google.com> <6335c05d-9493-4b03-85a7-f2dd91db9451@linux.dev> <20240606054334.GD11718@google.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: <20240606054334.GD11718@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Erhard Furtner , Nhat Pham , Yu Zhao , Minchan Kim , linux-kernel@vger.kernel.org, Yosry Ahmed , linux-mm@kvack.org, Johannes Weiner , linuxppc-dev@lists.ozlabs.org, "Vlastimil Babka \(SUSE\)" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 2024/6/6 13:43, Sergey Senozhatsky wrote: > On (24/06/06 12:46), Chengming Zhou wrote: >>>> Agree, I think we should try to improve locking scalability of zsmalloc. >>>> I have some thoughts to share, no code or test data yet: >>>> >>>> 1. First, we can change the pool global lock to per-class lock, which >>>> is more fine-grained. >>> >>> Commit c0547d0b6a4b6 "zsmalloc: consolidate zs_pool's migrate_lock >>> and size_class's locks" [1] claimed no significant difference >>> between class->lock and pool->lock. >> >> Ok, I haven't looked into the history much, that seems preparation of trying >> to introduce reclaim in the zsmalloc? Not sure. But now with the reclaim code >> in zsmalloc has gone, should we change back to the per-class lock? Which is > > Well, the point that commit made was that Nhat (and Johannes?) were > unable to detect any impact of pool->lock on a variety of cases. So > we went on with code simplification. Right, the code is simpler. > >> obviously more fine-grained than the pool lock. Actually, I have just done it, >> will test to get some data later. > > Thanks, we'll need data on this. I'm happy to take the patch, but > jumping back and forth between class->lock and pool->lock merely > "for obvious reasons" is not what I'm extremely excited about. Yeah, agree, we need test data.