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 7CEB6C433EF for ; Fri, 10 Jun 2022 11:44:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB5C98D0091; Fri, 10 Jun 2022 07:44:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E65FF8D0090; Fri, 10 Jun 2022 07:44:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDF768D0091; Fri, 10 Jun 2022 07:44:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BC7548D0090 for ; Fri, 10 Jun 2022 07:44:46 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9648D34431 for ; Fri, 10 Jun 2022 11:44:46 +0000 (UTC) X-FDA: 79562144172.30.5C5AF3F Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf12.hostedemail.com (Postfix) with ESMTP id 2B7FF4003D for ; Fri, 10 Jun 2022 11:44:46 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id B60B7220D8; Fri, 10 Jun 2022 11:44:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1654861484; 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=c2yNehDhwyQqo17iHRnrFd5b2B4xhq7rJYv9z6HMzWs=; b=h+J12/+6dA8PdIqRIwQ/dq8CBxwmkTtmJN+f1WSXzGepjWfdRUp6+83ihl6g6uUh9msQ3L qwEBdbkyLPmTrWlEDIIcEPJJpJ7gw2yT7LTS2tkfBcUYqvZX9r9bfGgNgjmvM1nTYHbhA6 iZFt0rZqsig307bTfbxENF96s0p7l0Q= 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 48F442C141; Fri, 10 Jun 2022 11:44:44 +0000 (UTC) Date: Fri, 10 Jun 2022 13:44:43 +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> <3f7d3d96-0858-fb6d-07a3-4c18964f888e@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3f7d3d96-0858-fb6d-07a3-4c18964f888e@gmail.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1654861486; 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=c2yNehDhwyQqo17iHRnrFd5b2B4xhq7rJYv9z6HMzWs=; b=FPmgXhNOyIzv2v1VmWwl3L1zw38H18dR+ebx8qmeiJXQNscqITzUSZ789hqGmaI6WsKrk2 FrJeFVIsYikGXxjOv+H0JGM7NKPvjm4WUq/zIykleVWZyHAxjmvTFK7Wz+ZXt+iurm9scw U47/4KE7vZ+uoWEOyz39DKznnt2PTzE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654861486; a=rsa-sha256; cv=none; b=gwoUw6BLRew5BEsp0LhNCJQ29rw8DVy9+mskUbsBxXc+uhrV7YlqxEofiEZt76aHKIkKxd 7pMW68BDCJ7jga84T3dTRpRnGU2k6FL+WiivyFBAhfyU4TYxcA33X7HfvW/+9RtcCm6pxJ /xcoM+bD36I4xZWd/sIL/t/O8d4lzIY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="h+J12/+6"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam11 X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="h+J12/+6"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf12.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Stat-Signature: ug3m59ah6zcqmrsjyfjf6nqdm5n737rc X-Rspamd-Queue-Id: 2B7FF4003D X-HE-Tag: 1654861486-584349 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 Fri 10-06-22 12:58:53, Christian König wrote: > Am 09.06.22 um 17:07 schrieb Michal Hocko: > > 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. > > Well I didn't claimed that this would be easy, we juts need to start > somewhere. > > Regarding the sparse file handling, how about using file->f_mapping->nrpages > as badness for shmem files? > > That should give us the real number of pages allocated through this shmem > file and gracefully handles sparse files. Yes, this would be a better approximation. > > 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. And just for the clarity. I have mentioned global oom event here but the concept could be extended to per-memcg oom killer as well. > > 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. > > Well, what is so bad at the approach of giving each process holding a > reference to some shared memory it's equal amount of badness even when the > processes belong to different memory control groups? I am not claiming this is wrong per se. It is just an approximation and it can surely be wrong in some cases (e.g. in those workloads where the share memory is mostly owned by one process while the shared content is consumed by many). The primary question is whether it actually helps much or what kind of scenarios it can help with and whether we can actually do better for those. Also do not forget that shared file memory is not the only thing to care about. What about the kernel memory used on behalf of processes? Just consider the above mentioned memcg driven model. It doesn't really require to chase specific files and do some arbitrary math to share the responsibility. It has a clear accounting and responsibility model. It shares the same underlying problem that the oom killing is not resource aware and therefore there is no guarantee that memory really gets freed. But it allows sane configurations where shared resources do not cross memcg boundaries at least. With that in mind and oom_cgroup semantic you can get at least some semi-sane guarantees. Is it pefect? No, by any means. But I would expect it to be more predictable. Maybe we can come up with a saner model, but just going with per file stats sounds like a hard to predict and debug approach to me. OOM killing is a very disruptive operation and having random tasks killed just because they have mapped few pages from a shared resource sounds like a terrible thing to debug and explain to users. > If you really think that this would be a hard problem for upstreaming we > could as well keep the behavior for memcg as it is for now. We would just > need to adjust the paramters to oom_badness() a bit. Say we ignore the memcg side of things for now. How does it help long term? Special casing the global oom is not all that hard but any future change would very likely be disruptive with some semantic implications AFAICS. -- Michal Hocko SUSE Labs