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 F1154CCA47B for ; Fri, 10 Jun 2022 14:16:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5067D6B00EC; Fri, 10 Jun 2022 10:16:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B5D36B0173; Fri, 10 Jun 2022 10:16:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 356198D009C; Fri, 10 Jun 2022 10:16:50 -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 20CF36B00EC for ; Fri, 10 Jun 2022 10:16:50 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C636C34C99 for ; Fri, 10 Jun 2022 14:16:49 +0000 (UTC) X-FDA: 79562527338.12.137E6FC Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf13.hostedemail.com (Postfix) with ESMTP id F0D8F20071 for ; Fri, 10 Jun 2022 14:16:45 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 5C5FC22145; Fri, 10 Jun 2022 14:16:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1654870604; 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=5V1brKH3JxuGnK163MHstZIpkveguOsr+QIbT4bxCoY=; b=NyQNSqMm7QuDHvrEU7zuZC0pzUg2RGEV/QNqY2FnmYqan0ThFcYQF/yJNBDlgKMUs+JA5d 0hIV8Eu1swzN5Qwl5Xkh9vy9jDc+jPIi1n9iq/2DomdScT+6hntA5YYLmINM3Q6MEVANUE rn3CgbId4neVU+zayaDyRfjkmdDG7pg= 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 F0BE42C141; Fri, 10 Jun 2022 14:16:43 +0000 (UTC) Date: Fri, 10 Jun 2022 16:16:40 +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: <77b99722-fc13-e5c5-c9be-7d4f3830859c@amd.com> <26d3e1c7-d73c-cc95-54ef-58b2c9055f0c@gmail.com> <3f7d3d96-0858-fb6d-07a3-4c18964f888e@gmail.com> <2e7e050e-04eb-0c0a-0675-d7f1c3ae7aed@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2e7e050e-04eb-0c0a-0675-d7f1c3ae7aed@amd.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654870607; a=rsa-sha256; cv=none; b=klj/xFIWi2Bj/KICYLSqH20dbbUj96D6NF1g7vXp774WstWvIK72UqaeN2RqTJWdGtoBwq LO3dO5gTpCdVBUXK6TwalHM1Nx+XGLNcLY3niT8n0I5/RDsjE+YUJfDlMt0ETjBPPuubWn /aIbt+ky24B20SJWJNu3NE3MKxerQqQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=NyQNSqMm; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 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=1654870607; 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=5V1brKH3JxuGnK163MHstZIpkveguOsr+QIbT4bxCoY=; b=56maJZKSt3N7GMMtEOUat8xivZ3GW5DI3hRDHI7sJQai3DO2rbQ3XbQxC3QBsUYQhBORVF cR5fathJ9e9qt0CbSUZfoI3UBbEAuOaAIWGoKpvbuyaC7rMrtlEGlIWQUXXNRmrDpASeBR 6Mh8gs3bKck6KT0jqZhF9+KNoT37qOU= X-Rspamd-Queue-Id: F0D8F20071 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=NyQNSqMm; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 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: 94oitifqi9dsoqryb4oe3hxormojtuuh X-HE-Tag: 1654870605-525101 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 14:17:27, Christian König wrote: > Am 10.06.22 um 13:44 schrieb Michal Hocko: > > On Fri 10-06-22 12:58:53, Christian König wrote: > > [SNIP] > > > > 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. > > Then what exactly do you mean with "limiting the scope of the damage"? Cause > that doesn't make sense without memcg. What I meant to say is to use the scheme of the damage control not only to the global oom situation (on the global shortage of memory) but also to the memcg oom situation (when the hard limit on a hierarchy is reached). [...] > > 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. > > Well, it does help massively with a standard Linux desktop and GPU workloads > (e.g. games). > > See what currently happens is that when games allocate for example textures > the memory for that is not accounted against that game. Instead it's usually > the display server (X or Wayland) which most of the shared resources > accounts to because it needs to compose a desktop from it and usually also > mmaps it for fallback CPU operations. Let me try to understand some more. So the game (or the entity to be responsible for the resource) doesn't really allocate the memory but it relies on somebody else (from memcg perspective living in a different resource domain - i.e. a different memcg) to do that on its behalf. Correct? If that is the case then that is certainly not fitting into the memcg model then. I am not really sure there is any reasonable model where you cannot really tell who is responsible for the resource. > So what happens when a games over allocates texture resources is that your > whole desktop restarts because the compositor is killed. This obviously also > kills the game, but it would be much nice if we would be more selective > here. > > For hardware rendering DMA-buf and GPU drivers are used, but for the > software fallback shmem files is what is used under the hood as far as I > know. And the underlying problem is the same for both. For shmem files the end user of the buffer can preallocate and so own the buffer and be accounted for it. > > > 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? > > Yeah, I'm aware of that as well. But at least inside the GPU drivers we try > to keep that in a reasonable ratio. > > > 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. > > Ok, how does that work then? The memory is accounted to whoever faults that memory in or to the allocating context if that is a kernel memory (in most situations). -- Michal Hocko SUSE Labs