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 0380CC7EE2A for ; Tue, 24 Jun 2025 07:46:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E32F6B00AF; Tue, 24 Jun 2025 03:46:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BB0D6B00B0; Tue, 24 Jun 2025 03:46:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D1086B00B1; Tue, 24 Jun 2025 03:46:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 59BDE6B00AF for ; Tue, 24 Jun 2025 03:46:17 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0834F161C9B for ; Tue, 24 Jun 2025 07:46:17 +0000 (UTC) X-FDA: 83589511194.30.E0CB368 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf22.hostedemail.com (Postfix) with ESMTP id 0D2DBC0004 for ; Tue, 24 Jun 2025 07:46:14 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=ZqBkz4yj; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf22.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750751175; a=rsa-sha256; cv=none; b=jEcTUCPd/IemVcmKCn8P7zOuBaE0lAwXMBywirMSCzQOuJmgkWoGYef+Xv0kYXcM1VVfZP 5yBPgnAqCgmkGMryGmB1pDkP4S+Z6c05nCDFAZbjT7NLPKIjrrsDE39tL6f3KophOKbVGg CxbpIDg4ZH2XYdS22wX/ch7Nieiz3zc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=ZqBkz4yj; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf22.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750751175; 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+oEhOHHx7fY+nLT2qN0EKVfCmE4uQzy+o05i8qDvec=; b=odLkhlw2/WKNuqGtWKRDPzMX2+BDDoIaSza/AcMCzhVtW8p+N0vi0E1eoOcB3qvv6j13uR J//GlIiTxYRxC3dCN4fZ8vDZAhVnqIOtwh0N9DStZMRTYhrDNlywRdK+4duxnuEsObTZMO I9Ru+gDaPcpDAbD6Lt3voDS15s+e5Tc= Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-55220699ba8so5496053e87.2 for ; Tue, 24 Jun 2025 00:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1750751173; x=1751355973; 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+oEhOHHx7fY+nLT2qN0EKVfCmE4uQzy+o05i8qDvec=; b=ZqBkz4yjiPXiHa6oiMbUhJ3rH3BpUNbz4q5/MJthDet+FCYi8IbEm/Sovli/9jPYqW hYRGoOqGoxNFgxitO8hNlH9eYzk3IauaV5rxTef73HBxZj8mcbL3j9zBCLplRYy4gMFE AsOJTnhyb/TGNOTk5iUaAjTcFgGqfzbW9J/BoIlW+hnL0Sx12FcGe8X+ROsNj8m8qDCk iWeJxlHz7bOQkXL+mvuEliEjTONO3hBjkRH5IvUaVK0Y/3Ze/wqSQrsY3K9ea3ggeLQo 9PMQeNE30ifxhssHwdoa6FC3mI1kWgPG0DDzeILSumRTQTHJHa+YD0Fbwl3phrdEXVYe hFkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750751173; x=1751355973; 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+oEhOHHx7fY+nLT2qN0EKVfCmE4uQzy+o05i8qDvec=; b=kMU7GWasU+0YQq24dyJFH11+n6sIIrF6R5nmtXjPwQVTqRVuFKY07EcWvFsh3WFcuO 0NuXaaIPK9sYJn/3LSMLGvCCwbSgwTZTIM1FaTL0axZUZp8UBVrQh5mpmuNYlCoDxwnF FI/KWDhAWEKKXgwWQe2YN2rRpIL2Mv1kuWS2NXQ8OGADUWtqHL0yLOaCNOdw4/kUiKJv ZB5JJA+7gk8yGnfX8LJggKPefFLnqFmrIffRK0In04VY+umD5d3TJu8SHX5BqAzOu4cf dSMd9KQgujSPOztUDexCmIB4ZsCm/DYFXtHYuWMM6l7cOIiNBA5JJbaa6ZyHITcAhFJU gIvg== X-Forwarded-Encrypted: i=1; AJvYcCWvYk6T1/CygkVi23uzJQt/eNyH+A+qcE4jnZxfel/P6icm+7aEooTKEnXVh+Juw3xdtBs5grJs/A==@kvack.org X-Gm-Message-State: AOJu0Ywj2kRZx2BsZjHdWNZu3Sq5T3MpTfHiCXE5iEE2L7jnBNw/RSe8 sXg6IiAE4VSOveA7xnzU6ZRSZONo4/YxeGxnAUNOKT9CR5d6TzQJXSM/F8ROJBk9MqwWJo8Vh0c pR72YLk4gj593+w8MlKcfrOP/AEXerG54WTlt/qO4zQ== X-Gm-Gg: ASbGncvYjaJSQwOrypVbv/7PVdt44+Vs71ZB/yjVXJD28JJ0TSjY84BJKmaNK/OF2WT Ujqlk/WFxpHGJ/Fz7kEQvRdGxRaDvugUn+tvBltiVeOMocN9iLjJ3IADcT45I4UtWHeV3YmZrbJ xldhFiVcQg6SyctMdthIcmBfi9hV/CApp9jlpN9kbZ75qkqcc2fMfOiEgW X-Google-Smtp-Source: AGHT+IFeYUZar2HVowmkLYZSd2STiizR8hFaF4uq0hhzYEvud8WPf+pSSuVw8h7oTS5swY4X/pPSyhdh3F2k1DRwzJc= X-Received: by 2002:a05:6512:3e04:b0:553:296b:a62 with SMTP id 2adb3069b0e04-553e3b99018mr5116928e87.12.1750751173353; Tue, 24 Jun 2025 00:46:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zhongkun He Date: Tue, 24 Jun 2025 15:45:37 +0800 X-Gm-Features: Ac12FXz-Z4gUKGi6BIbRPkGEyqVXiKtjI_FOE1Vnun9s2B37mLTDpYjLgI0Qdmw Message-ID: Subject: Re: [External] Re: [PATCH 0/2] Postpone memcg reclaim to return-to-user path To: Jan Kara Cc: Shakeel Butt , akpm@linux-foundation.org, tytso@mit.edu, jack@suse.com, hannes@cmpxchg.org, mhocko@kernel.org, muchun.song@linux.dev, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 0D2DBC0004 X-Rspamd-Server: rspam10 X-Stat-Signature: rasxxsgu4hc833ton5gprm93m97t5spn X-HE-Tag: 1750751174-786270 X-HE-Meta: U2FsdGVkX1/6p4c+x7t0xCaY1F1shLN09yCSimk4/1ciH+EzBOZJahhMJzN7uYv2/+GD1ZO0cCQL8iIVSEtthvW1DA64L92M7ZcJ116sabyH3xFPBaKKQ2vtdkUgEeNHULdUw+/AwR5Ttk+HM96R8LcKTf2hCPQeRi79rdhc5tAQNhHfXQ/o4qC6f9RTveaKBnqeT45g2ddVphHc+Zw3FGwg/k0a5E7JykYNktV75oJly1BgC+lODazX7zyn5u2R6DAohpWFkKGfgxmUE/1UVE76JToHK9dc0GviazBBgbsktL9dZnOpy6g5xu4ysJ1UmxOK4pCDIatam6b0rMMUcsvpr8N4+QT7krqNyFoX/lsa3C1Z2ILCmSAjSLEkU+ENNWU9g7IsRBLBMM3AXkaoVQ/buiaiwmjDBeatHjQtlnQ68vAUNfRt183u4piWglhk8QmPuzW7OsSYiMEWvLV5JhC1S2caiWMKGlOM/Z3PYcFI0EFynistVnKWCy+D2ztg7N3EITLiCeOzZG6fhacQEphf4gD6shkQxwnY8FC+qhBa70Z8A0gD/Ka4L5uIsDHemxPHGJBs8BokbfI6hd3ChIXipposUqo+GMGrOSyk8yz2Es072mo8D1KDcMoMOoSpX2HJJmauyHx/2n2BPqnFiv8dHhN3zXJXt4vFbNihFb5jflQ9HxUX+MVfw10Nr/ygBm1DnpDYyC9DthzuS05IfgZwE9jidlFkb+d9AczHLKo9GUT4DCXIJq7FRaqwcVgYBNH78nBz5/4GcBvWnBffTP2V9QMHstrItTJy8Kbu7r7fnepxJ7VcXfK7dmVOcFmL9juRSsgb4wcrgmrXVjJv87AlpFqN8Q+gq8ALDAOLCvBhQibVvahuy2H/dWIHjOXh/+d1ey1Jq+0aNsIQ+C7SZeyvxRVwcmgTmtMIoQWhOR/mGgfR3LJIaKR7kqedigaNihACLJmghb/qb3+Fwyj 84RhT9Om L0PvkjmbfNmAETcXjPCrKudFJsQr+ybJ3gEfCwG5rKiLxrt/ECcINQLUGw3SjsVTiLHgcs/4oIR0ox+blgOR330zmGHsTMv+Sgrn3j+2YP5uRFCZDfituLLS2oxyOrHS09RqoIjz2R7ftBVQDARF3v9GGp7I6s47PIGI5kWnFzPkrWS+X1LdnfoIapwbbhodhjML7UKUHERKyR3tvo0xTjtPVY8knR5OCgo5zWRxdzvLf4KGvVZ39mIYjD4md429xpwZSzj1gQqOF8Fg= 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 Thu, Jun 19, 2025 at 4:05=E2=80=AFPM Jan Kara wrote: > > On Wed 18-06-25 15:37:20, Shakeel Butt wrote: > > > This is > > > beneficial for users who perform over-max reclaim while holding multi= ple > > > locks or other resources (especially resources related to file system > > > writeback). If a task needs any of these resources, it would otherwis= e > > > have to wait until the other task completes reclaim and releases the > > > resources. Postponing reclaim to the return-to-user path helps avoid = this issue. > > > > > > # Background > > > > > > We have been encountering an hungtask issue for a long time. Specific= ally, > > > when a task holds the jbd2 handler > > > > Can you explain a bit more about jbd2 handler? Is it some global shared > > lock or a workqueue which can only run single thread at a time. > > Basically is there a way to get the current holder/owner of jbd2 handle= r > > programmatically? > > There's a typo in the original email :). It should be "jbd2 handle". And > that is just a reference to the currently running transaction in ext4 > filesystem. There can be always at most one running transaction in ext4 > filesystem and until the last reference is dropped it cannot commit. This > eventually (once the transaction reaches its maximum size) blocks all the > other modifications to the filesystem. So it is shared global resource > that's held by the process doing reclaim. > > Since there can be many holders of references to the currently running > transaction there's no easy way to iterate processes that are holding the > references... That being said ext4 sets current->journal_info when > acquiring a journal handle but other filesystems use this field for other > purposes so current->journal_info being non-NULL does not mean jbd2 handl= e > is held. Hi Jan, Thanks for your feedback and explanations. > > Honza > -- > Jan Kara > SUSE Labs, CR