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 C4E80C433EF for ; Wed, 15 Jun 2022 13:15:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3908C6B0073; Wed, 15 Jun 2022 09:15:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 340C36B0074; Wed, 15 Jun 2022 09:15:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 208AD6B0075; Wed, 15 Jun 2022 09:15:27 -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 127826B0073 for ; Wed, 15 Jun 2022 09:15:27 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E224B20469 for ; Wed, 15 Jun 2022 13:15:26 +0000 (UTC) X-FDA: 79580516652.05.C684603 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf13.hostedemail.com (Postfix) with ESMTP id 36AF720093 for ; Wed, 15 Jun 2022 13:15:25 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id BF13A21BB9; Wed, 15 Jun 2022 13:15:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1655298924; 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=17VEqNPV/TBk73G7tKfWD0AkIggznFYMqcz7zsD4S9c=; b=c5CplPzuxQh5gnp4bD34uWkKLEOaOc1Tpwslt5ARBi5fVdHjWZ4prxmWoQqcdCpqAG1Yor xmQuGVnUEOpCEt1XYqn7LUtFrFvMKUMl0YDT2F/jRq/vq+FW+bBxji/zHIwKJ8jaI2QMZs rqLOKCpvqZTZhxAjHRYVGQZVY5XNs10= 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 66BBD2C141; Wed, 15 Jun 2022 13:15:24 +0000 (UTC) Date: Wed, 15 Jun 2022 15:15:23 +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: <2e7e050e-04eb-0c0a-0675-d7f1c3ae7aed@amd.com> <288528c3-411e-fb25-2f08-92d4bb9f1f13@gmail.com> <34daa8ab-a9f4-8f7b-0ea7-821bc36b9497@gmail.com> <9e170201-35df-cfcc-8d07-2f9693278829@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9e170201-35df-cfcc-8d07-2f9693278829@amd.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655298926; a=rsa-sha256; cv=none; b=hhxFHVNXnYBeB75+nDbrYDry/c0WOGvWYAP/DbKZVUIJwvTdKlUbiwx2UFm4fIYcUbGChd Imk3nXY1p5Pn/+vHKPZi4CeWsjS1dhCUm5u//ZpPSUjNyt0oeMtciACAgz0RE0fHxfvTqE IxH313OivHS+M7kTaclwUeNEx1/adEo= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=c5CplPzu; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf13.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=1655298926; 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=17VEqNPV/TBk73G7tKfWD0AkIggznFYMqcz7zsD4S9c=; b=HYRy2CNe577bkNabA4xBP9F7YJJfvyl13wuvByAmoRlw9Qj5iYamWrog2JPc7YYtXMO+tf yjIwzsccB3c9aYGDN/ctYdV8ltAb/TTq57c/CQIDw439+qec+oZQQULG7dyKi6rEeH314u INGp6iYk/whRfGjFwbjp+JwQ+Cr/osM= X-Rspamd-Queue-Id: 36AF720093 X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=c5CplPzu; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf13.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam06 X-Stat-Signature: ehf698nqcktep8ko9w5xxks5fqyadobi X-HE-Tag: 1655298925-241980 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 Wed 15-06-22 14:35:22, Christian König wrote: [...] > Even the classic mm_struct based accounting includes MM_SHMEMPAGES into the > badness. So accounting shared resources as badness to make a decision is > nothing new here. Yeah, it is nothing really new but it also doesn't mean it is an example worth following as this doesn't really work currently. Also please note that MM_SHMEMPAGES is counting at least something process specific as those pages are mapped in to the process (and with enough of wishful thinking unmapping can drop the last reference and free something up actually) . With generic per-file memory this is even more detached from process. > The difference is that this time the badness doesn't come from the memory > management subsystem, but rather from the I/O subsystem. > > > This is also the reason why I am not really fan of the per file > > badness because it adds a notion of resource that is not process bound > > in general so it will add all sorts of weird runtime corner cases which > > are impossible to anticipate [*]. Maybe that will work in some scenarios > > but definitely not something to be done by default without users opting > > into that and being aware of consequences. > > Would a kernel command line option to control the behavior be helpful here? I am not sure what would be the proper way to control that that would be future extensible. Kernel command line is certainly and option but if we want to extend that to module like or eBPF interface then it wouldn't stand a future test very quickly. -- Michal Hocko SUSE Labs