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 E54E8C43334 for ; Thu, 9 Jun 2022 12:57:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D43F8D0015; Thu, 9 Jun 2022 08:57:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7830E8D0006; Thu, 9 Jun 2022 08:57:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64A4C8D0015; Thu, 9 Jun 2022 08:57:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 567398D0006 for ; Thu, 9 Jun 2022 08:57:06 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 17C5421312 for ; Thu, 9 Jun 2022 12:57:06 +0000 (UTC) X-FDA: 79558697652.29.64E6CA0 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf20.hostedemail.com (Postfix) with ESMTP id 867D91C006C for ; Thu, 9 Jun 2022 12:57:05 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 7B10021F24; Thu, 9 Jun 2022 12:57:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1654779424; 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=U28j2PjZN2oiqvKxhUnwyd/bN75hpBsh2AgbH09Uz7A=; b=cFkohmjy7k4OX9d1OaQPtTN9EE/zJV2ErpgiPH7m8blNWJJ6BBZeoEmEz449KI0rfzy2BA XVeJQYaCgUF2mN2YG6+08pn+iSIHSyBrXQeAga+1sko3yRfSLWaHAiur5hWq9muNl5oJnw q766pmidjn9XorGZeH2GHV38FRhBu+g= 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 3EEAD2C141; Thu, 9 Jun 2022 12:57:04 +0000 (UTC) Date: Thu, 9 Jun 2022 14:57:03 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <77b99722-fc13-e5c5-c9be-7d4f3830859c@amd.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654779425; a=rsa-sha256; cv=none; b=Cro/GzBjFSZ38aA461BWkaNDS46DiC5NikRMgCl7iiuqrS+B4yyhoUhxI+zISB2eKJwH+j 62e4rnPw0VL6YAOvc9lcofG6ULxK7iakLU/OFOve2aH1Eb3lGCQ5psS2AOhN2xBZTJyEN9 2/Z/jf0zgaJdS1SnNXTHLja+uYEZKvw= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=cFkohmjy; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 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=1654779425; 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=U28j2PjZN2oiqvKxhUnwyd/bN75hpBsh2AgbH09Uz7A=; b=oLm/clZQQ5cS3/GSmqJrIxdMt8LtEHDpaAyYiHsfeO9913/6MJgo97H+W/JxCFt+IWitTe T+dcekmRV7hrre1lUkqgah9bEs5k/4uSih5/t3xLPmCP/p+nDoW7xDmZ6kmgdP3GkhdtkR XQ1wpj7UFQppR57u0WE6SHb47WU6Vzk= X-Stat-Signature: xzpuf54uqdifkt8nwgtdrakx8ptk9qpy X-Rspam-User: X-Rspamd-Queue-Id: 867D91C006C X-Rspamd-Server: rspam07 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=cFkohmjy; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1654779425-782299 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 14:16:56, Christian König wrote: > Am 09.06.22 um 11:18 schrieb Michal Hocko: > > On Tue 31-05-22 11:59:57, Christian König wrote: > > > This gives the OOM killer an additional hint which processes are > > > referencing shmem files with potentially no other accounting for them. > > > > > > Signed-off-by: Christian König > > > --- > > > mm/shmem.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/mm/shmem.c b/mm/shmem.c > > > index 4b2fea33158e..a4ad92a16968 100644 > > > --- a/mm/shmem.c > > > +++ b/mm/shmem.c > > > @@ -2179,6 +2179,11 @@ unsigned long shmem_get_unmapped_area(struct file *file, > > > return inflated_addr; > > > } > > > +static long shmem_oom_badness(struct file *file) > > > +{ > > > + return i_size_read(file_inode(file)) >> PAGE_SHIFT; > > > +} > > This doesn't really represent the in memory size of the file, does it? > > Well the file could be partially or fully swapped out as anonymous memory or > the address space only sparse populated, but even then just using the file > size as OOM badness sounded like the most straightforward approach to me. It covers hole as well, right? > What could happen is that the file is also mmaped and we double account. > > > Also the memcg oom handling could be considerably skewed if the file was > > shared between more memcgs. > > Yes, and that's one of the reasons why I didn't touched the memcg by this > and only affected the classic OOM killer. oom_badness is for all oom handlers, including memcg. Maybe I have misread an earlier patch but I do not see anything specific to global oom handling. -- Michal Hocko SUSE Labs