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 00391C27C53 for ; Fri, 7 Jun 2024 09:41:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 841E36B00AF; Fri, 7 Jun 2024 05:41:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C95E6B00B4; Fri, 7 Jun 2024 05:41:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 643C56B00B8; Fri, 7 Jun 2024 05:41:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 47B706B00AF for ; Fri, 7 Jun 2024 05:41:07 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BAF20A17BE for ; Fri, 7 Jun 2024 09:41:06 +0000 (UTC) X-FDA: 82203598932.17.D96277B Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf15.hostedemail.com (Postfix) with ESMTP id 09B1BA001C for ; Fri, 7 Jun 2024 09:41:04 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jYZvtezI; spf=pass (imf15.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.52 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717753265; 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=k/oSqpRfe691rKkuHYiQBq4OSn10B5HpGWWM65PH/D8=; b=uHyJUCRf9iKJzcL0ppSoGDGHawnUgmkz6A7FjABPDXi/WJSY9PWsQW7uIDRuMRkGyqLs+U R8K9A8ykjNLLJOzOwsrJmrc8AzUCYmi1Y1I5rbgQU8hlv/hB6+28XxLK3TyLRRndp4MMTb gMjzNjV4ggoK7pYZ2OBJoBFKO8ivv0I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717753265; a=rsa-sha256; cv=none; b=ORLcJN7H/YkqxMY/v4mXV+aOsBNwOa2XtcYxALuy8aLkAZbQWo8hcJdk3LpFR1lgbUCDYH 7wQokRoDWuxjfeLTUiyh8/oa5RC1OJw2tRJnWShb1qtsCoAgPfzp3yjDL3iX14XLWCfxZc ZAps90vGvfJE8z1zoMZ6oEVLXVGLp8Q= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jYZvtezI; spf=pass (imf15.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.52 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-6ae279e6427so8962806d6.1 for ; Fri, 07 Jun 2024 02:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717753264; x=1718358064; darn=kvack.org; 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=k/oSqpRfe691rKkuHYiQBq4OSn10B5HpGWWM65PH/D8=; b=jYZvtezI2JpOt8vk/JOKvckcFZbULGyNSAQUaoct8aS0u4cZ+kgjW+jMZ8LCEJULAB R7JR5z8uNQ+4KbxX0OHbQK3nD8lXEXfmMTrfhu2P85Ugfac3t+Zo/3OCttib8jDu4UMf iDC1ydwPB9K/JYfBxLVDIH4x8C3RCd4GG5eEG2x9DKDuK+rigZveB9uLLpnR3cyP3e/o 7GQp0HCs+g2/Z8kDZjiZ32tLJHe2wMJMZyqtxja7ZIxLxX2LD5FizLuR3Dri7o1nk3wv h/kNTH9Xq/NN0y/GinYkhIbVR6Fd+k9jUTwzZDyT/+d1/U+xbNdJBxQ2447/tUF2pRSR m1gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717753264; x=1718358064; 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=k/oSqpRfe691rKkuHYiQBq4OSn10B5HpGWWM65PH/D8=; b=j+8JdG0KFr01Y+07ce2FJ9ux00BcHAxY28UCqHmyhRj2oOT4LwbqYjZR8qyyJyzqXY 0KPJzUZhhAmOoyFcWaKz+jk3aaf0Xrk6M44+Rjvmdi/CpQ5tEbOek36qEz+HoOLUv9uX gBnW1PySfiENPyG4ElEb46Go8FC4Rl0rOK84BokM6dMigVBpjlQfyxi+DUHiGKozFYVk GqPblkYSan3ryuh7XGypzG73rtbV826AKEZwWj4aw4819le9hIZV6aGVcFeL/YY+CDAx FSkqYa2bsEMyDoKVagdjRE8NnAK8D+Wm8c/kgzrrFjtyrQIq+MnbjdOHaD6XE/hLN1Y0 vFqA== X-Forwarded-Encrypted: i=1; AJvYcCUcgyYLuvKf7Y1U1Wnz3yPagP10Jn4M5r0QL6XNG1hyvBFGXDeJODZvBOexPUDkYqCfxBT7RseVTodEF3a+RfdEZ0U= X-Gm-Message-State: AOJu0YxA90EZUfkGjsFhcWEUvawV4a/EamyXzGxK4ITzK0BCHhKyM1cT 1AzCf2C2E8pxcwnt7sr3/93a4vO+Wykq0Hv0YqeY9a/RviDJtL7tzfP0GrKQKPd7mzaeWqOx+YJ BnYR1ZnLrCqoUl4Y4hhAntl4yWq4= X-Google-Smtp-Source: AGHT+IHn0b6EwReH7VI6F17pOZO2Pe20rM3RuA+jzTt8WWs3Xl1Tg5kPGQ/pBjjGZKYKADka1oStpZieFokTq4hFc6k= X-Received: by 2002:a05:6214:534a:b0:6b0:5933:3a8a with SMTP id 6a1803df08f44-6b059b851a8mr20938446d6.15.1717753263959; Fri, 07 Jun 2024 02:41:03 -0700 (PDT) MIME-Version: 1.0 References: <20240604231019.18e2f373@yea> <20240606010431.2b33318c@yea> <20240606043156.GC11718@google.com> <6335c05d-9493-4b03-85a7-f2dd91db9451@linux.dev> <20240606054334.GD11718@google.com> In-Reply-To: <20240606054334.GD11718@google.com> From: Nhat Pham Date: Fri, 7 Jun 2024 10:40:52 +0100 Message-ID: Subject: Re: kswapd0: page allocation failure: order:0, mode:0x820(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0 (Kernel v6.5.9, 32bit ppc) To: Sergey Senozhatsky Cc: Chengming Zhou , Yosry Ahmed , Erhard Furtner , Yu Zhao , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Johannes Weiner , Minchan Kim , "Vlastimil Babka (SUSE)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 09B1BA001C X-Rspam-User: X-Stat-Signature: fee9a9fyy7ur59xwbeqhm4i8uauppemg X-HE-Tag: 1717753264-156409 X-HE-Meta: U2FsdGVkX19O1bBvluafPa0E81lmHrvvHPb0+s45u5YxTdGvts3LJ4zjocuKMhvKPFhGwqFXBrDSgV67hxl3r0dAPnhtwb3YnACVebcbMfZ1f1k+Fq2XEAIoBrs0eXFLh8PXnIwB1VBgvaNreu0beERlNt76QXaf7AT6MgkI7P4G7uEmrM27ix2Xah8kFWBjUkKS7fJ0gbMqgM9JK2s9ep99W1AkFn8Myrnjlny9U3BxtRuzPsKXvfaCE6oMxV2Jw0IjSa1mqQBy5DxdxL5oi9jmus3me1DLSrhPQr7CG46U0z3AchfntjPkROjx6X8NqerXg2MLqgYqJXMJHvoW+EFFwzooru/ohl6nTv8BeBiPYTee4qY71PBKJ+F+ellHSI42qhfmzNf0tsB3UKgDF7PWeUff/3fk3sAOQy4OwQSmDH9uFBgsl0OzzNIooH8K2/0uyakcFvk3m3ivhi4oLmbADKi9GtZUfk8oSNVWAXCDfz/fweyCet06QWhbZmffUuD28FxLgDiqW8EKNXoH+lVO+vE+6QpwyysyWnr41pwof4Gr5VlYM307YG8E8uHcWtVnbQyDlIYl2aQMr3d+g1Kjna44vhU8SeCDWPaMGLjmUH7rKE0EkIiUEEstsVMw8z5JAuygnpbXEyxZ7jVnx96hAUHIxaPTsq7JTqCsrJbdpGa0ahvLiWQdjZ1/zdFQnlgSW0sWAVXV23LnyKqUJ8xrX3SbgdrHYN5KCMqlW36DAXPmN+wv/Gd3X8DPH1XFvo4y1YtaRAm4ZrlEUQlQZdmrEYo3kDCkUaY0eRAvU656fUB1dQD63up5qGJd1Lv86xvtsXN8M5QHsqfxWA9TVdv/r4Q0chyh2l4eVMLPvLXqZxOBNYygqfIWz+wMt02E8YXs+wD2k5fBv9wJjUgSD5w22nb2dLlgK1qrOchxTtPr0LFuSxvG+VDB0Dpgc+gVc/qhVLL53UJF8UI17sp BHV6ZxpO +2Qihxskv9olLEQEgcm0s70C92LhxpX7GyyWPIVswzhRWweAdWzXuETkrBRcIgM3XIJjNTnz8MMN1XO4zBReVM9QUFg6INWCWhNNimONZFptrDW9BzbMANkgGvBNyk+nh97v3f9k1Db2BmiXyWOLvccAxhGANdxmZxtp8tTrNLIuoMOy2D3AjGJNkqL8GWM2vQgLBa4fz8Iy7uAiPMpFYUG/wEJpdso8NId6zH+xwkMDS8bk0PWrBEIHnd52Yz2W1dQukMXjb2T2D5VHZAROxRaXyzkJ/7ulosVOWGuBI7snKJ4Qu0ymMa/O0HsxugwJYfzEeAf0Gsm3jYnvRxJZDxrWm4j5jEA8mmmW8Jh6tifQoQSdaykxj400cejXdfEL4QhjYxKw5ce2WYsAG/K4mPbqk0TjezwzIsLsmnid2YmGy26Z4iOO/QFZjzoZzWez7eG3QJif1vBmu04o= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 Thu, Jun 6, 2024 at 6:43=E2=80=AFAM Sergey Senozhatsky wrote: > > On (24/06/06 12:46), Chengming Zhou wrote: > > >> Agree, I think we should try to improve locking scalability of zsmal= loc. > > >> 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, whic= h > > >> 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 t= rying > > to introduce reclaim in the zsmalloc? Not sure. But now with the reclai= m code > > in zsmalloc has gone, should we change back to the per-class lock? Whic= h 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. Yeah, we benchmarked it before zsmalloc writeback was introduced (the patch to remove class lock was a prep patch of the series). We weren't able to detect any regression at the time with just using a global pool lock. > > > obviously more fine-grained than the pool lock. Actually, I have just d= one 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. FWIW, I do think it'd be nice if we can make the locking more granular - the pool lock now is essentially a global lock, and we're just getting around that by replicating the (z)pools themselves. Personally, I'm not super convinced about class locks. We're essentially relying on the post-compression size of the data to load-balance the queries - I can imagine a scenario where a workload has a concentrated distribution of post-compression data (i.e its pages are compressed to similar-ish sizes), and we're once again contending for a (few) lock(s) again. That said, I'll let the data tell the story :) We don't need a perfect solution, just a good enough solution for now.