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 F12D6C3DA61 for ; Mon, 29 Jul 2024 08:15:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 221E16B008C; Mon, 29 Jul 2024 04:15:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D1C06B0092; Mon, 29 Jul 2024 04:15:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 072C96B0093; Mon, 29 Jul 2024 04:15:28 -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 DB8E56B008C for ; Mon, 29 Jul 2024 04:15:27 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5A095C01D1 for ; Mon, 29 Jul 2024 08:15:27 +0000 (UTC) X-FDA: 82392080694.01.BFF4039 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf06.hostedemail.com (Postfix) with ESMTP id 1293118000C for ; Mon, 29 Jul 2024 08:15:24 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=SUw0bCOk; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722240898; a=rsa-sha256; cv=none; b=Q31+S4TeD/bbsaml7Agb7VAhTCRi6omU+uleZLahbMDf1vTBcT9eB9zu1ifluSc7VsqUtQ OAK9PLNLJYRTxe5+TSA8F3BnP7rE+gid4BkkOPKW0my2nmYW3LlNzKeUuZRsBvfmIdhY0A 5UFc5Nguptf3MS+OHORuT76tYu0idQM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=SUw0bCOk; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722240898; 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=HVjA+bIcDpbnmzrciVh7kfXXZ60SEX5d5fn8ZISA1a0=; b=F5aM9+z52vj9q83WvALptcZz6yYq/FMEadUPM6J7I5u/uvx1LdfUmTlHaWwomO2aOr7bXC FqsRuWEsQectnZ9uZaMOq1m9cWbK0NGZaxv4jVwqCA0gFIH7ZAwfgzmgREKwVUYlLPfRQY ruL5DZ0Yr5HeoplD0ST+/ZQvxZ2TPwQ= Received: by mail-lf1-f44.google.com with SMTP id 2adb3069b0e04-52f01b8738dso2946767e87.1 for ; Mon, 29 Jul 2024 01:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1722240923; x=1722845723; 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=HVjA+bIcDpbnmzrciVh7kfXXZ60SEX5d5fn8ZISA1a0=; b=SUw0bCOkZ0KKIlvbRWiUQpTMLsvpYvjYjN8zSctRyySxAUrzzfbKULmH4EqfZKnj/9 jNBvxDr0H8xpgT9LnBcsDmtJaR5Rsv6u0ynVg9nNY6UYkgAtOVeIUdAw623v7OoSHi3G kSN8BofNK7HZsxRR/JURadq7VxT7egEf/Kg95Tcm2VL+TMR+BC2BT12SWMlwENtnuYDV xQrS7BE2I0/ILc1AluMlePkzlV9nW0GzHrfCd/Q7NY78tArextkZDFQamMqP3OfXsdqw yiiEa8x02dMgrOid+FVxPLAFHgiEzIfB3HvM3LWESl1DSb+zEay+UwHOInkkO8dkRwHk xuaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722240923; x=1722845723; 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=HVjA+bIcDpbnmzrciVh7kfXXZ60SEX5d5fn8ZISA1a0=; b=pRiyAzZT7QOA4igGh90ahHsspbJxeXTo9JR7t39eaoSYuf3cs1gpGI2N2NvUpjz1o+ ctaJ2jb1cz72cNDqfHD2Qig+arRbus79Lf/HwabtK96uNhMgNuiiXS+XfYns9Fxe3LlI riziM+pyIfD6aA6+o50uFbiQQd2YQx+qTtX7bktzVBf+seGHykuaIIbj6OGoWUHUBmMF +8sCRERSy7XY+JGBF79wq9JmN5gxwaH/oG/PtuRP5W+YgxFEhqR/JJhn3JXmBjs68NMM FFfNoj0QoqIGOPB6UdvldGTIHkObT2IjD9ZvOFm5d/puJdlyMStpDCCCwUae0UpStZx1 YHrg== X-Gm-Message-State: AOJu0Yw5aSW2siiosKasdjh6bQeYJbK9AeEA0WEzDH7zSdRDM+GPRA7+ /qtvQiHalb6nN6qjjhPeZ8MK7dr8+vr9bKUGDfv1qEUFJmIh0fgdWR6w7Agw8XM= X-Google-Smtp-Source: AGHT+IFF0GdXCJWlZ8ukklf/dMO/E41NY+i6ecCIGsXYbN9H3J6/AlJLOOvOiZJPQdEcApWEDd3TOg== X-Received: by 2002:ac2:4577:0:b0:52c:db75:9640 with SMTP id 2adb3069b0e04-5309b2cc9edmr4382676e87.48.1722240923262; Mon, 29 Jul 2024 01:15:23 -0700 (PDT) Received: from localhost (109-81-83-231.rct.o2.cz. [109.81.83.231]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7acadb9f60sm472861066b.223.2024.07.29.01.15.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jul 2024 01:15:23 -0700 (PDT) Date: Mon, 29 Jul 2024 10:15:22 +0200 From: Michal Hocko To: "Zhijian Li (Fujitsu)" Cc: "linux-mm@kvack.org" , Andrew Morton , David Hildenbrand , Oscar Salvador , "linux-kernel@vger.kernel.org" , "Yasunori Gotou (Fujitsu)" Subject: Re: [PATCH RFC] mm: Avoid triggering oom-killer during memory hot-remove operations Message-ID: References: <20240726084456.1309928-1-lizhijian@fujitsu.com> <2ab277af-06ed-41a9-a2b4-91dd1ffce733@fujitsu.com> <264840d7-d770-29a0-7c36-6ede9063d06f@fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: k33c6qxqbu4a9hqpjaankhhg1yhrqadj X-Rspamd-Queue-Id: 1293118000C X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1722240924-873458 X-HE-Meta: U2FsdGVkX18nos5nmF3n+klPHqhjYovIAoWw8+cXYwsA/bA+suNEcz3Snr3mqG/IxKlY3w3BFF3VuWGVhyBNFV/lUgfhKqWZ7nsGrbsp+YNrfELf5rOV1JFNiR5ax48hCosjvIEUyU84KHpq4WZQ1V9gOnxRQtVbuLGBNwzbNCnFo9ZJoTzJ4nZfZ5Uc3Z2V8KLOi8krZ1+KzyHUMHUtSGqHt68f15dJy9ihpb5fHYmJR9d/o+tSlIuSMg2solKCVkGArlru+/enphTlOaCX3u7XPuU+M22rT4Si91PJDGvvBjkfkn+cFbGwvS8Q/7lfawBurJWO04lpXCpRs3zVhwABxDaOTNdNNqYaD/wvJv2UXTf65dsYhmiy3mwUxnuHo6RS3LdyIvMhFaIEQ46BJg+advUYZhnShdM+wdC+HFi9rvds21xjm/p3obeOlSoIkgzXUkdyWRybm3FBjJoxgfc0Vh/r7SOg6T1jCX2X9tWavrSXI4zPQkGo61uIbxuV65/dZowAtLG3rpH6E/apcjD2f8SUwxAkNoDOTH73Bf/lv0uDrnHAVqKoB0pL4Yh3Pu6q/Yiv5eLB1WiSDCZq63hhhBWmD5Ll/d7d5+Sh9XVfAPXT1IZIGVEvlr32cgv2dvN1b/nTP3xD/4jw0eNKEsfqANnN0h/b2mIrrbO7BLwDw/ycIQoOE3cwgXLiGK9uaFX8Nz59usY6ihxbDOZOXceAo+6XHXYVwynDnbjakLeczPJV1VQTwuYVmGv63w9MJxQO3ANrzFyVjdBbrmG+zPQ4TlCo2BOMbO82bkXFn7Jd615M0MPwAhm8p1tDsRD9xAbaTMoraNTztmIYCdWouX3P8d0c1ausSwMhdJgyr9fnWtlB++LJ1uNxBXvxkJb2AM82b2faXeOMdADfyxWAJ3OnJMWgNYgg/KETdc+dUEpYulL6oRyA58kIP0iAEOgFQ7qj0x3ETqC/4fQaTSs N21ui8tM uWW3Lycn6LDmZxe6148tr9Y3NG31Ee2saofRNcp1S6cA7tie6bmzowA8vjz20uuRz9ezjwojiTE4L81XSHXNOSiTTfA1H5Msi8rmgYrIdIknTb/N9t+n+/4qp+QgcbVy16lUNbGFXe4XUq1Iiwc4jt32ZP27JQuj+5iikZ5hJsivysD9Mm0kF1pG+9PXm/UHS++Cbc6v0hfs6DibtICdKygyEKhPTupL6XFVCH/0WhuiDcPMFbTMXNV2ZwsRH9PSaOZorMDd+nPJpDQKtnfVOwKCmbmEbj6r3hLHu6nTag3UAZeDuDEiekHJo+NJwu0Cp5j3jk3dc4TYYWmSaG9+NT8r4m54+jfkzmMGmib6fnjrxg6dACA5Oxiq9vhXn3/uKiocUNlemvFFc2hHqTc6A95RaEpJdzlqn2bO3efcEX0cjgDF1e/n6gj2CJkb05FovPllo 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 Mon 29-07-24 08:04:19, Zhijian Li (Fujitsu) wrote: > On 29/07/2024 15:40, Michal Hocko wrote: > > That means that rather than killing the > > test program which continues consuming memory - and not much of it - it > > keeps killing other tasks with a higher memory consumption. > > This behavior is not my(administrator) expectation. Well, this lack of proper NUMA aware oom killer behavior is there since decades without many people complaining about that enough to push for a better implementation. So while this is not great it seems not that many people are suffering from that. In general dealing with a complete memory node hotremove while there are applications with strong numa policies is quite hard to do right and there will always be a certain level of suffering. > > This is really unfortunate but not something that should be handled by > > special casing memory offlining but rather handling the mempolicy OOMs > > better. There were some attempts in the past but never made it to a > > mergable state. Maybe you want to pick up on that. > > > Well, tell me the previous proposals(mail/url) please if you have the them in hand. > I want to take a look. https://lore.kernel.org/all/20220708082129.80115-1-ligang.bdlg@bytedance.com/ btw. lore.kernel.org has a great searching engine. > >> [13853.758192] pagefault_out_of_memory: 4055 callbacks suppressed > >> [13853.758243] Huh VM_FAULT_OOM leaked out to the #PF handler. Retrying PF > > > > This shouldn't really happen and it indicates that some memory > > allocation in the pagefault path has failed. > > May I know if this will cause side effect to other processes. This eill mean that the #PF handler has failed to allocate memory and the VM_FAULT_OOM error has unwound all the way up to the exception handler and that will restart the instruction that has caused the #PF. In essence, as long as the process triggering this is not killed or the allocation doesn't suceed it will be looping in the #PF path. This normally doesn't happen because our allocators do not fail for small allocation requests. -- Michal Hocko SUSE Labs