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 51097C54FC6 for ; Mon, 2 Sep 2024 03:01:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C20C68D0068; Sun, 1 Sep 2024 23:01:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD1928D0065; Sun, 1 Sep 2024 23:01:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B0C88D0068; Sun, 1 Sep 2024 23:01:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7A3758D0065 for ; Sun, 1 Sep 2024 23:01:00 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2DF821218F2 for ; Mon, 2 Sep 2024 03:01:00 +0000 (UTC) X-FDA: 82518296280.26.05685B1 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf09.hostedemail.com (Postfix) with ESMTP id 650F8140017 for ; Mon, 2 Sep 2024 03:00:58 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ev72DvNo; spf=pass (imf09.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=laoar.shao@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=1725245965; 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=edAOJAmsZw3975fOsodLPJi2UQo+cY3XRH19urTIDbY=; b=c4WOkNHh3/VWDLa7Gnz4gfQhZnoe0/MhbkTelXH3bFxaxAvpj0ghAn6pK2++Gwg2tQHzVq PZ5qh+dDIPz5BaRbanF9DRjatnEsz363eLTzwS2YJ26tWkCSaualBLJ+EtbMf5qRtoaG+8 n8Ol9FHyPxVKWt90oK6Bzn/7iHNzktU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725245965; a=rsa-sha256; cv=none; b=GaGU95AQf6w3Bv57nyDukKzKkO0sdVC9s0qB9p5J4WQ4Fw3xgFdBxLNR+YgPsDkpiUUXSD artvEG3/7ptEbj2LLkwo2EB4K6L2Kv+e2wzQ3r91PLAGIFJMbwqjOTk4q8miwGEytUT+PG 7cmo+/FXk4TQ+a7+5cdSFT4/gBGLyv8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ev72DvNo; spf=pass (imf09.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-e179c28d5e8so3922393276.1 for ; Sun, 01 Sep 2024 20:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725246057; x=1725850857; 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=edAOJAmsZw3975fOsodLPJi2UQo+cY3XRH19urTIDbY=; b=ev72DvNo9TFwvm/Z3bxtoGJNa7jPdrxAMuyLrSPJh+P1CmJhFKieO4KRXLbCimHqXe RwHw1SpLIomhmzeu33noYIxKx+PlPNP8BTLJXCh40ggXgwvypmZG4ra80K6nvE3dv/fl fbVUB5Km+IFR6xYd5d0tJVT812cWgsnW9O5fyXmpQwQ/N0MaIljo8RW1JnqworWX46uK epkR1zH2SpSpnfZDefG4aMW9WLLlXAnSOJ1wnBcz9Xge1JS1wdvdmPak0UEMYoN4mcSN /GYx70ZU3ILeHL00I2ztWdbwBpcz+9pCAgL4jHcHOO2nNzBFcJ9FGadPG9SxbXfqdfeB Cggg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725246057; x=1725850857; 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=edAOJAmsZw3975fOsodLPJi2UQo+cY3XRH19urTIDbY=; b=gs7sg8jfOxrpZrb5WC9f/7mD1ZDNJKxSttWGgsve4sUlve7Gdf96DrdO6qD+Us6uBb H+Lm5r1mAj4GgA2KAF6D8icJNTJ2JdVNq3feQS2mrXSrhKd+tU/Bnnh9AC6ZXy4G0tm9 fnS7FT3VnI1GYGsbGhUi7stfMiep8tq6QCQksDck2fZ+/jxBagGNU7a4JEgSSJLCgtrS b2Q8fQCyemFmwY5kBrrldgBgUCUEgQfeaGPy80YuVUcffpOo/IFvogRKPU5FRCChjWcv LyVt+bPRRnu8cZFCDQBBTav/1TXRHnXcBgxJEXp7+BkUqKiKWJ4e3xEOlUC711PvGoWp 2FZQ== X-Forwarded-Encrypted: i=1; AJvYcCVYsPLGEn/zge91ACpSiH1ZoqqzC/nVyMVpCcZeKFX82Q4r6oa8LiTUGFM3Jx8dRX6QGWkXItYfGw==@kvack.org X-Gm-Message-State: AOJu0YwKl7+P5UjeA3pOa9brcccsg53kkyMSsMM9jd61PJQLgY61HcBO +QFNufCq6ipltk+fzXhFIQNnx41m1uyRnSS47M2gOs2tUy7JhWtPgNeoVaEmEJmFY1lOMY99qID XYtlx1+1YbzDvteErAaosqultN4o= X-Google-Smtp-Source: AGHT+IF5Cjbyc1u2E5YIqEaXq1jH6gbFBHgZFuhUPu8+BRfDQXy8bRu8L1XCnhFIKLjj0jYfWHQ9t9TKxlFN9rT5L8o= X-Received: by 2002:a05:6902:c06:b0:e16:19f7:9702 with SMTP id 3f1490d57ef6-e1a7a01cc00mr10955110276.24.1725246057273; Sun, 01 Sep 2024 20:00:57 -0700 (PDT) MIME-Version: 1.0 References: <20240828140638.3204253-1-kent.overstreet@linux.dev> In-Reply-To: From: Yafang Shao Date: Mon, 2 Sep 2024 11:00:22 +0800 Message-ID: Subject: Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc allocations To: Vlastimil Babka Cc: Dave Chinner , Kent Overstreet , Michal Hocko , Matthew Wilcox , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Chinner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 650F8140017 X-Stat-Signature: zrfhjmzdpcsdjqs1zrpfjgmoor98ahs4 X-HE-Tag: 1725246058-566047 X-HE-Meta: U2FsdGVkX1+pHtYD3ZXiaR1R3qCATq9UkOm4vdGh/M/BsyVJt9Zg/xV1139JU6JXHyRHG5LFwKd+sFo8MNHetTrz+71rCDg1cUkD9jPZslZvsIYLx/cjuPyO/bfR0jyPSg+RBvkhodL3lQHhttvCweGefTxCYjw63nNrP9JZrloBPY5RJLc2EvOPg8vHT/Xktel51ltqdwiI5Qhm62Q45V2tH9NT7msxJl3lDr51JlaIOiTOEZaJCxleAQ8rk9rvciqRof9v8me5uTwKCbLjehSmB/nXW7nUstjlcxzKRheit8+ArkPddqc9RWMK7RfcF9orR21p4BaUHYAIXp+vQKOPn0rpJTBq68XDioLdybKN3MXG40fZ+q5vrbA9c0D8SFyncgxaxipYjWuWd8ERRWliw6ImF9p9320vDwyZwq9zJ4hD8R9TFiYHzwc6mMjqegrI/ftZmiDEDG4piQFEPf8W4ypP90yqlJs+r96CBBlXKWsh+sPkHBR3ZxHDAnpv9STVIGRVRD/1PYaOYE781kqt3S2BAgOkozKciIdrfpQ2sXJRvQLAjlUZ/XxhJuaT4CsUgJdSpD8AbQsXIdK4E46GnoDWKXMUwnVkzYR/06Ybe3MZ1GrY08KcmQbB9WFr1mKEqe44rjY4BbUJKYUb8Bn8BHwAe2bOjcUTwQLVcVsS6QIdcFC7/f8r2GA1jtKlW4wyQZHkVgis2w8VWcoUt0cqvZ7HMadj4P7Fa72f+57TrODxWXHSkUQMDWZTIqrWv2Tf53jsqGpyX7N5kVl0tm4AOLySONAlKAz3jUV4gt3B0nHq6KSbtrRGhT0daJLVJr1G/43dZnK3rh7EXJ28fNyG1DhPWq3YHK590e0YkrCIo3GWc43H03aZehVnk/Lu9/qaap6f73ScexngVHq6gM6sl+3Z/Ot45Rn+naIY0RCZXq5tM8tOGQnQGf1T3ZpPgia8ASJ3LVYsNbRGQv1 cXLa9foh Sk5EMUE/CmId+S4dkois2dq28JlYiHUunnlDPS0V/k/ksyconu9T59GATjXjzTVIHQkOK04kONRJsG6HeO9pCXVP5TSIprV6vuYmiKjDvbUAGmsjY/+lgkulxQNqyaLuzSdiX8fFEVkj8GoGhErwBaxHXHc9AjcIb6gohId69xIfubeo18AWwd/82Gqk5wec4pTtSPyCIE1m2O6hCOaj36qahMrj26NH/rIOBFRtz4y0BqLQobRu0Y+zkYFRwzSbCgnlrDm+74J3BsT7bUyjL2VirR00QV6c7T7sj4sw8iwbMJ2vOpowKuo90kpLOvMKkelaKUxcB40M+2GNEd4XEjeKvZKKJRuMIMKJQjTdQXoHO7Wpaow+mDj6E1GpTO0OTgSpbNsGIrKTxFNCQ3Qd+jBEv2GYS4XPYmsRQ2IojR9p5EXLmgQNvk8xi4g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001513, 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 Fri, Aug 30, 2024 at 11:25=E2=80=AFPM Vlastimil Babka w= rote: > > On 8/30/24 11:14, Yafang Shao wrote: > > On Thu, Aug 29, 2024 at 10:29=E2=80=AFPM Dave Chinner wrote: > > > > Hello Dave, > > > > I've noticed that XFS has increasingly replaced kmem_alloc() with > > __GFP_NOFAIL. For example, in kernel 4.19.y, there are 0 instances of > > __GFP_NOFAIL under fs/xfs, but in kernel 6.1.y, there are 41 > > occurrences. In kmem_alloc(), there's an explicit > > memalloc_retry_wait() to throttle the allocator under heavy memory > > pressure, which aligns with your filesystem design. However, using > > __GFP_NOFAIL removes this throttling mechanism, potentially causing > > issues when the system is under heavy memory load. I'm concerned that > > this shift might not be a beneficial trend. > > > > We have been using XFS for our big data servers for years, and it has > > consistently performed well with older kernels like 4.19.y. However, > > after upgrading all our servers from 4.19.y to 6.1.y over the past two > > years, we have frequently encountered livelock issues caused by memory > > exhaustion. To mitigate this, we've had to limit the RSS of > > applications, which isn't an ideal solution and represents a worrying > > trend. > > By "livelock issues caused by memory exhaustion" you mean the long-standi= ng > infamous issue that the system might become thrashing for the remaining > small amount of page cache, and anonymous memory being swapped out/in, > instead of issuing OOM, because there's always just enough progress of th= e > reclaim to keep going, but the system isn't basically doing anything else= ? > Exactly > I think that's related to near-exhausted memory by userspace, If user space is the root cause, the appropriate response should be to terminate the offending user tasks. However, this doesn't happen at all. > so I'm not > sure why XFS would be to blame here. Honestly, I'm not sure what to blame, as I don't have a clear understanding of what's happening during memory allocation. One server among tens of thousands in production randomly experiences a livelock within days, making it extremely difficult to pinpoint the root cause. > > That said, if memalloc_retry_wait() is indeed a useful mechanism, maybe w= e > could perform it inside the page allocator itself for __GFP_NOFAIL? Perhaps an additional wait or exit mechanism should be implemented specifically for __GFP_NOFAIL. -- Regards Yafang