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 9FD04C02180 for ; Wed, 15 Jan 2025 19:41:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 347CA6B0085; Wed, 15 Jan 2025 14:41:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F6DF280001; Wed, 15 Jan 2025 14:41:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BE866B0089; Wed, 15 Jan 2025 14:41:40 -0500 (EST) 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 EE65C6B0085 for ; Wed, 15 Jan 2025 14:41:39 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 919111401D8 for ; Wed, 15 Jan 2025 19:41:39 +0000 (UTC) X-FDA: 83010705918.24.672485B Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf25.hostedemail.com (Postfix) with ESMTP id 64081A0003 for ; Wed, 15 Jan 2025 19:41:37 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=F5fWDdhu; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736970097; a=rsa-sha256; cv=none; b=8FPdxJ512nfdC8Hh0abDlJX/lHvMtWX539aqg7o8qLZU9xES7jscTuwU28bu3AGinnSTsT RwRb7RzKjf9xCE346kL6S+sRhu+X9nMyZrvhQKOtuzX2Jj1TiriPxSI61jGN3fEP+S4ydw dMS7vey+GpAwPMFnFiPuiXpyoFhLUVk= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=F5fWDdhu; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736970097; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3ZVNqrTwKIYDf4Bm8NNK5jPuTo2WMdjzDg2Q0uygxvA=; b=h7cFtSxbi2gK0v90iqu7Yx+zzVj4aIdfeHdlfZEKLEhQEChlg2FhCgG/n8mzhn+JfJMef+ LEsNdLqZrB56enam0NwDOZiuS0l37iwjhJjz1vl7JPtZbDGXvssDfYCdDCYWqrFrh6/NNn Rl9kC0qJPUGegpYi4FJ8M7KNSLW8B4o= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5d3ecae02beso159248a12.0 for ; Wed, 15 Jan 2025 11:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1736970096; x=1737574896; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3ZVNqrTwKIYDf4Bm8NNK5jPuTo2WMdjzDg2Q0uygxvA=; b=F5fWDdhuCE02xDQYJq9NegB/qiqrd3Eu0gH38tjYdGxR06LtvMLE+jBzYB2NpUdS54 Hrn5jmkmqS/vtpyDqFVsIJhHXbgrEnL4ZjM83J10foUmLlbQuN6Dp58NOukTFTv3vHel x2laeF3y3Nvr9ZpiWNCQffFDPh79tfntHDyxQMNzdOl27oapPqpusa7d98LfHOaHsQ96 /jiP4c0+WtCshSIvD9I7FIcP70SFL/1urxwqOwZvDiBgBAHWuGU18Fojm0qjW6qbPoGb MhTGoXdpBl2r6vZoAiSb/H0ewYTI1JaX/YrLQ5/UPY55RCAowPjU7R85fe0ZGkKo/zcA iW4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736970096; x=1737574896; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3ZVNqrTwKIYDf4Bm8NNK5jPuTo2WMdjzDg2Q0uygxvA=; b=SUb4u79xFRRKvjwc6d3KcUudZISIJRio84n5vahacy5eVCTUqZk+YiiE1/W/9qpC4r UkbGbUMKZgjh8ADwQFbktaC9rhFERnqhBxH89jGCgLad9K46UAPOUuJAM+RNyQMZzXfP MoqBYKU9JO29B1mU74aDT47h/K91CjJXdJWYWGFAdE0uIE30a2L93ulQc3YIuLQkqHvw xh7MMygoZEq5qjI/oAifrtOoNuY8fJEl4lVHcSlV025Ilk6ZSqq0iy8fVdk7igjXoPET vungFdCt9d5MTJMq366gKFMpDN2iTrIWINRmETr4VtA5nyCw5uKfRKJkv+bcnK4lITgO jeZg== X-Forwarded-Encrypted: i=1; AJvYcCXO0p6F3SPBK6cTzjvaIEDkEldzXIFXdyiK2p6DNkUry2L4zQ/+2LUbAfFcq4qhVD1J1eHRc3lYxQ==@kvack.org X-Gm-Message-State: AOJu0YxxlE+zHJRDfWgngSvj5UvDUZqZ3Vyqm/sJUNWQd/7gYZyHALLh PRDz/Ua6Mw3ce2zMemzlIOoWPjXZPifgeNZNFb0Gyl1v8r0e5/43q4QrvcE5qYc= X-Gm-Gg: ASbGnctMbEGWsnpd2fRLkHnQmOqlweUYwpKoEQ8x052dzRhKSPQh9uV2CeBVr9YNtYc Smkh5rKgo5XVDGuZcops4GFERpzjU9RLCnDj97KjdtCiVzN4hnbgKpb4zyGW3ShAqiN4Vga2ydI Ai0bxZw0vjUkjWAQlnxrn2X6DAbLafHpmMQ1mHU4pGhmcHIjGzdU2Aw4UEu0/nIGVih6fTo6V+Q n3zQzKANb04EdkScNzFc2fWtYiKGBMDvfddv4/gMaSMNa0pwsMNwz3LeSQKvHgAfr6c7A== X-Google-Smtp-Source: AGHT+IEQAuyjYMWDuvxbQji30YXDQg1tnXpQK7ijaXsvEZSUIwVzPcfJ06q+Oo+0/rOilCVxe3Nb/g== X-Received: by 2002:a05:6402:4307:b0:5d9:f362:1682 with SMTP id 4fb4d7f45d1cf-5d9f3621964mr8968077a12.24.1736970095771; Wed, 15 Jan 2025 11:41:35 -0800 (PST) Received: from localhost (109-81-90-202.rct.o2.cz. [109.81.90.202]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d9900c4326sm7629912a12.23.2025.01.15.11.41.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Jan 2025 11:41:35 -0800 (PST) Date: Wed, 15 Jan 2025 20:41:34 +0100 From: Michal Hocko To: Rik van Riel Cc: Johannes Weiner , Yosry Ahmed , Balbir Singh , Roman Gushchin , hakeel Butt , Muchun Song , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Nhat Pham Subject: Re: [PATCH v2] memcg: allow exiting tasks to write back data to swap Message-ID: References: <20250114160955.GA1115056@cmpxchg.org> <193d98b0d5d2b14da1b96953fcb5d91b2a35bf21.camel@surriel.com> <20250114192322.GB1115056@cmpxchg.org> <7a4e5591f45df455e6a485fc5400989569d3d22d.camel@surriel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7a4e5591f45df455e6a485fc5400989569d3d22d.camel@surriel.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 64081A0003 X-Stat-Signature: g3a9ez7kbb6geqt4jrwrpdf517jtmx4m X-Rspam-User: X-HE-Tag: 1736970097-321987 X-HE-Meta: U2FsdGVkX1+Zr+xq0h9F+zgnOpKhVD3i++cGRsNizXN25Cv1hbPvfYmVjO6I5d85zMLf/fcVQzV9r5xsNVcSSDw2ZhquBl0lVOukQHiaS/ePnLRiD3pjmoJhxkBJXzqecV6PP/XvjzggRDyVeSz+LBDad0IzxP782LrfJlnrTLJbKKqP/KOEznM/Ho7ff0OM88WiYqtiMCAkhj3WQP4g7YzECZqZX+HhNauTrfkf9yIQbfhFjXr/B63In1AyAUFrKttTxGiL3M9zRqh+1oQosZCEhG1LD0tX22xMEse0x9sJCleIspGfrlhE/lR7bA3r9QcxG8f53RxeHbNVcipOq2cjs2L6oHADEH3x6Vk4O6YWNwDkIDfuq3QyNHhs4w02lK61e3ktuHVFc83rL4bWxFBuoMiyDKVvxwx+Wuj3s56/zDRGyBvFNiHiZ1rr1f6nWDey68OWliiGpP7SMUXt00iFeV9Mu3Qbs2f47BX+cdylQOUL5eW2FgjH2M9PCYoI/jbhbJzOmS5faRt+qeStNMm9Q5j8xVHtrBI1xK2VlPmHVpETGR4KLGFkTpPd+cLekqDvLEer5NgRP3a4s9ZK/FB9g2h6bE8VquTpMgPeDF/6UeXWd4BxeEe7rZf5goucgpcppf++RsgeDfJ/OCojl4nG0BzBkp34FURnA2y/ajiiUZB6k4zLE9fUsudHVNryn8O7rAyS0DvRwiPaqHpR6VTlt7FQjCZkvmt3BmxjIsaaRA5r659tyXyPnpk4tyYakGyHlSEduUcAoiP4wKA3mid7yy8de2xmY8LNC3wmP+Tz8d9GBdxnJ8zepQ1qCz7a1LtrmzbTOjKqrQcyWh4pcKVvTcbxor0yA3ejLAeM+XXTf77pbrenLiAWi3MiaZnJRTSC1a0E0iZkI8ygUDfzTjMu5torP2ssUcyyN9/+fJG2kDSZIGDZxhb2p/Do8Rwo5L3AZ0YwQpTtNnNg5Gd jBawb5Q0 BpSq31sRc4KMpfci4+eAf8eMpr4l5d1BCJZBcl4WVLe8hf5viIDZTGTaU4g3s26tukug/fuOXFJ5rYuAP7VDvvVEqaTg3apPE1pe0EJgRg3NDjClXsvWuoKc/orCAhMS0PjJlLf+ZB4Zs8Sp2lz5xy2qOlAwYM+NePtCWHMfZs7U5Y0WO8TBONBWo9NezeMUpJCCSEE1c1ZUldm/XreP0Pd6a3gSZ/EUvJSqPhHYHOPslq2CsAuLfTCDYdAJ/bTrLlaAJkc2f38kksKRD6Z+c/dADDiyVmU2+51CCx9sORlXHLcNIzx+CufAAA1SV6YVk5EFnogfm40aBfPCS6UdOdGajEC5mef+x7baZW7W5ko4TpPU= 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 Wed 15-01-25 12:35:37, Rik van Riel wrote: > On Tue, 2025-01-14 at 20:42 +0100, Michal Hocko wrote: > > O > > I do agreee that a memory deadlock is not really proper way to deal > > with > > the issue. I have to admit that my understanding was based on ENOMEM > > being properly propagated out of in kernel user page faults. > > It looks like it kind of is. > > In case of VM_FAULT_OOM, the page fault code calls > kernelmode_fixup_or_oops(), which a few functions > down calls ex_handler_default(), which advances > regs->ip to the next instruction after the one > that faulted. OK, so we do not have the endless loop. Good. Sorry I didn't get to read through the fixup tables maze. Thanks for confirming. > Of course, if we have a copy_from_user loop, we > could end up there a bunch of times :) Yes, the robust list might have many elements and if each and every is swapped out then this can take a lot of time if the reclaim path is desperately retrying the whole reclaim. All that being said, does the change (partial revert) suggested by Johannes diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 7b3503d12aaf..9c30c442e3b0 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -1627,7 +1627,7 @@ static bool mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask, * A few threads which were not waiting at mutex_lock_killable() can * fail to bail out. Therefore, check again after holding oom_lock. */ - ret = task_is_dying() || out_of_memory(&oc); + ret = out_of_memory(&oc); unlock: mutex_unlock(&oom_lock); Or is the exit still taking unbearably too long? If yes maybe we can help to ENOMEM already killed and oom reaped tasks earlier? -- Michal Hocko SUSE Labs