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 C1A0FCCA473 for ; Thu, 9 Jun 2022 14:21:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50D368D001F; Thu, 9 Jun 2022 10:21:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 49B468D0006; Thu, 9 Jun 2022 10:21:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 30FD28D001F; Thu, 9 Jun 2022 10:21:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1E93A8D0006 for ; Thu, 9 Jun 2022 10:21:12 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D2A3CE90 for ; Thu, 9 Jun 2022 14:21:11 +0000 (UTC) X-FDA: 79558909542.31.D7B9EF7 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf19.hostedemail.com (Postfix) with ESMTP id 45AF01A0063 for ; Thu, 9 Jun 2022 14:21:11 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id CBBB01FE8B; Thu, 9 Jun 2022 14:21:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1654784469; 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=fY1GGI2PmNa9I/bhZ0fwzUE7IhjxYe1c+FuipaBGfM4=; b=WZBqe2Ngc57dpZ7Y9YIpBMWIEGgtumFc7wHEEmS3iMGOErxmCbDE8Y4kutoItwMX8mXOot aI38i6FM3xM1D1L9ytfvCrvrCh274JSZGEs2spz0dIdXONggDsS4OArMC9r3EchMRvbyoB Fra0izLAWYuEpWfzqf3+ibWKEYv1Htg= 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 7E6282C141; Thu, 9 Jun 2022 14:21:09 +0000 (UTC) Date: Thu, 9 Jun 2022 16:21:05 +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: <26d3e1c7-d73c-cc95-54ef-58b2c9055f0c@gmail.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654784471; a=rsa-sha256; cv=none; b=5oxaNJgK9ZVG565phqUuLmBLZNwILCJaaPjELM9pxPEe6cmo0BOGwahMaGwR6/W/x/wTBY /AxK0JRQ91yXKitcO5mVzclKVX2XOFSCUo/NPRJAtqthoGG9kKsDloUPnrAkTAg4bSN6GJ mSmvtVrQSLAG3yxPcTry2wJR1gkKrek= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=WZBqe2Ng; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 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=1654784471; 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=fY1GGI2PmNa9I/bhZ0fwzUE7IhjxYe1c+FuipaBGfM4=; b=JYrkOb690LM89HwbB9IyV5forfIT0s2EC0+27tJBBpRjoDK2QXl6xtR30U3zRUONOec3zz F+qiAEBDKWbjA9PX7uPsd3JfUpnfGbDEcOa5/UZ+I5lnN9FuD1Yibh5mRTznvqFIOVIxwl SUMuqgIZauqdLzXUJJFdl0TMdgz+IO0= X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 45AF01A0063 Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=WZBqe2Ng; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Stat-Signature: 73dt63unyw17zh9ippwbgtssck8w9gqs X-HE-Tag: 1654784471-639719 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:10:33, Christian König wrote: > Am 09.06.22 um 14:57 schrieb Michal Hocko: > > 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? > > Yes, exactly. So let's say I have a huge sparse shmem file. I will get killed because the oom_badness of such a file would be large as well... > > > 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. > > As far as I can see the oom_badness() function is only used in > oom_kill.c and in procfs to return the oom score. Did I missed > something? oom_kill.c implements most of the oom killer functionality. Memcg oom killing is a part of that. Have a look at select_bad_process. -- Michal Hocko SUSE Labs