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 10591CCA473 for ; Thu, 9 Jun 2022 15:07:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62FF28D0025; Thu, 9 Jun 2022 11:07:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B84A8D0022; Thu, 9 Jun 2022 11:07:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 431DF8D0025; Thu, 9 Jun 2022 11:07:08 -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 2CEC88D0022 for ; Thu, 9 Jun 2022 11:07:08 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id D524634D08 for ; Thu, 9 Jun 2022 15:07:07 +0000 (UTC) X-FDA: 79559025294.09.456DB52 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf21.hostedemail.com (Postfix) with ESMTP id 12A961C0084 for ; Thu, 9 Jun 2022 15:07:06 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 94DBF1FE1A; Thu, 9 Jun 2022 15:07:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1654787225; h=from:from:reply-to: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; bh=5ijNQJtk6i4bS4QWxJisxGyfX37F5AKbQDFufqaSXZY=; b=r0GH8a8OMYz9qCxwYnlpQdqJcDdzr81y+7Q96zHtHvv7mOhAiBSBx5z5skJYQuheM9fyrP OhwVH796ac6EGIP82Wqxy84XKU2xF2Fw406nnsVzRyzdtn3sZ8tyeYubU4helxrxefY3Ms g4pszhJLgKRiq4sTvLytSaOCon18h8E= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 4A85F2C141; Thu, 9 Jun 2022 15:07:05 +0000 (UTC) Date: Thu, 9 Jun 2022 17:07:04 +0200 From: Michal Hocko To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Christian =?iso-8859-1?Q?K=F6nig?= , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-tegra@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, alexander.deucher@amd.com, daniel@ffwll.ch, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, hughd@google.com, andrey.grodzovsky@amd.com Subject: Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files Message-ID: References: <20220531100007.174649-1-christian.koenig@amd.com> <20220531100007.174649-4-christian.koenig@amd.com> <77b99722-fc13-e5c5-c9be-7d4f3830859c@amd.com> <26d3e1c7-d73c-cc95-54ef-58b2c9055f0c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654787227; a=rsa-sha256; cv=none; b=13bnutqgmZAc0jpjTrEo+cp+vs1KPjzew7AWJo8lSIxlgNnVANi76y5xFSaXVfeV20ONbf WnsvUILmQI5dSY/xHT+rKJsOrU06SmLcxx8PxP2wOlKN03Z8LG65lUk4zcxQcEf1Y63jEN Z0eI3Gi6TvQwAkSDzl95qzCROEXOaIc= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=r0GH8a8O; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 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=1654787227; 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=5ijNQJtk6i4bS4QWxJisxGyfX37F5AKbQDFufqaSXZY=; b=RnVlBUILCHC6eFggzPHbkSGiiZPXzUw6MJa2CJRwJVFe7+/hYHui2OfICjZqLsZ+0uCbkZ nvLopN1mJ1dbL+F3hmFCdRtuS7TSH+OCWoI1cw+rUVhJXRUthzSElLgg74JuFbdlS4eGdT 416KVqM+b3vQc5Y1nfp4X64vsGqlph8= X-Rspamd-Queue-Id: 12A961C0084 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=r0GH8a8O; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: ompfbkdmkk1rc5ce1rzfe1d3ir1mofet X-HE-Tag: 1654787226-543154 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: On Thu 09-06-22 16:29:46, Christian König wrote: [...] > Is that a show stopper? How should we address this? This is a hard problem to deal with and I am not sure this simple solution is really a good fit. Not only because of the memcg side of things. I have my doubts that sparse files handling is ok as well. I do realize this is a long term problem and there is a demand for some solution at least. I am not sure how to deal with shared resources myself. The best approximation I can come up with is to limit the scope of the damage into a memcg context. One idea I was playing with (but never convinced myself it is really a worth) is to allow a new mode of the oom victim selection for the global oom event. It would be an opt in and the victim would be selected from the biggest leaf memcg (or kill the whole memcg if it has group_oom configured. That would address at least some of the accounting issue because charges are better tracked than per process memory consumption. It is a crude and ugly hack and it doesn't solve the underlying problem as shared resources are not guaranteed to be freed when processes die but maybe it would be just slightly better than the existing scheme which is clearly lacking behind existing userspace. -- Michal Hocko SUSE Labs