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 2B568C43334 for ; Mon, 13 Jun 2022 09:09:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5BB88D016C; Mon, 13 Jun 2022 05:09:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B0BB46B02C8; Mon, 13 Jun 2022 05:09:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D3E98D016C; Mon, 13 Jun 2022 05:09:01 -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 8D4EB6B02C7 for ; Mon, 13 Jun 2022 05:09:01 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6352E353E1 for ; Mon, 13 Jun 2022 09:09:01 +0000 (UTC) X-FDA: 79572638082.19.47A97E5 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) by imf09.hostedemail.com (Postfix) with ESMTP id 82431140085 for ; Mon, 13 Jun 2022 09:09:00 +0000 (UTC) Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4LM5N73Srsz9sZR; Mon, 13 Jun 2022 11:08:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1655111335; h=from:from: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; bh=/diBHTT7FJGtxv9Ix4yOBCZ8RnU/aeUMZMRq1jZWVd0=; b=Znxifht26gApX39S8dBdMlCkItNVWLXnXVPMEVWY3AG9zAT6gRrWMY9rhTZyANLJTCXA+T /Py+ybJGqRWT/5GkeLRhJZiWzDalGM3ZvZadEpQEYyYCU21C9ACURqw1LrNyUVHsOxWjvx 1p9izA8OmzrQ5cxuRmCiyhEfNhVce3b+LqtSrMJHG1exvU+qFVCJb9AZGKmxkawe7s4w+F /Xrajo+QQRwLwU5ACiJOqV5anBx0ps2Y2wIrqp32YeXJCOeBwJm20EiuG6GVGM12Bl5Dy4 ebLpFyJ47wP6J1/GG07XltI+NvUdJKpT2sZ8ndEXg24vYNlBTBRianCdqohCbA== Message-ID: <51536e97-ca5f-abe4-b46c-ee3eb57f891e@mailbox.org> Date: Mon, 13 Jun 2022 11:08:52 +0200 MIME-Version: 1.0 Subject: Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files Content-Language: en-CA To: =?UTF-8?Q?Christian_K=c3=b6nig?= , Michal Hocko , =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: andrey.grodzovsky@amd.com, linux-mm@kvack.org, nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, hughd@google.com, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, daniel@ffwll.ch, linux-tegra@vger.kernel.org, alexander.deucher@amd.com, akpm@linux-foundation.org, linux-media@vger.kernel.org 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> <288528c3-411e-fb25-2f08-92d4bb9f1f13@gmail.com> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= In-Reply-To: <288528c3-411e-fb25-2f08-92d4bb9f1f13@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MBO-RS-META: 577iphbxb4bs3945taqe58kkqzbs8imi X-MBO-RS-ID: 72e59480f2d70ddaf00 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655111341; 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=/diBHTT7FJGtxv9Ix4yOBCZ8RnU/aeUMZMRq1jZWVd0=; b=5lVF+9qlz8HpBQ4xhraBlThoskT5bXqjSYmdFOdb0ng2pgkmQL/rBWVRwj4lhugJMfmbJW Vyl+yFP+hC0ItDEVcwwVBakb6ExHSF/wyYVIqovjVyWPAMtD678s51yM2Ts4vJOJYJPm77 KicBJKQHi6nBzKhpt6VgrujG0XWWpx8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655111341; a=rsa-sha256; cv=none; b=sEYnM5j/+ii7K+BHVHV2njGqatBkgi6zA2ZAEU6UtyzV8vc1CJCr46jCR6i2q31Gx8VILS LhyXbQRGM5w29igTEkyXUQTbZ6uDDDX6JmNHTF2maq/G4GpugN0TirXWj1LdkjiA+YdrlD zD55lmRQZGSkKCW+PHjUexolZUIi+Sg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=mailbox.org header.s=mail20150812 header.b=Znxifht2; dmarc=pass (policy=reject) header.from=mailbox.org; spf=pass (imf09.hostedemail.com: domain of michel.daenzer@mailbox.org designates 80.241.56.171 as permitted sender) smtp.mailfrom=michel.daenzer@mailbox.org X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=mailbox.org header.s=mail20150812 header.b=Znxifht2; dmarc=pass (policy=reject) header.from=mailbox.org; spf=pass (imf09.hostedemail.com: domain of michel.daenzer@mailbox.org designates 80.241.56.171 as permitted sender) smtp.mailfrom=michel.daenzer@mailbox.org X-Rspamd-Server: rspam03 X-Stat-Signature: fpyh6hr5ij5x51xnnbtscuwbttt7t45x X-Rspamd-Queue-Id: 82431140085 X-HE-Tag: 1655111340-711880 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 2022-06-11 10:06, Christian König wrote: > Am 10.06.22 um 16:16 schrieb Michal Hocko: >> [...] >>>> 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). > > That's what I had in mind as well. Problem with this approach is that file descriptors are currently not informed that they are shared between processes. > > So to make this work we would need something like attach/detach to process in struct file_operations. > > And as I noted, this happens rather often. For example a game which renders 120 frames per second needs to transfer 120 buffers per second between client and X. FWIW, in the steady state, the game will cycle between a small (generally 2-5) set of buffers. The game will not cause new buffers to be exported & imported for every frame. In general, I'd expect dma-buf export & import to happen relatively rarely, e.g. when a window is opened or resized. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer