Received: by 10.223.176.46 with SMTP id f43csp702422wra; Fri, 19 Jan 2018 00:26:29 -0800 (PST) X-Google-Smtp-Source: ACJfBotaG/zZrk5Bx9hUJvS+C8kdk4orbd9CMT5YIOU2nqHEMip+rXkQxmXTEpp+ddgM9O6QNS5x X-Received: by 10.98.11.218 with SMTP id 87mr10990159pfl.99.1516350389341; Fri, 19 Jan 2018 00:26:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516350389; cv=none; d=google.com; s=arc-20160816; b=0hFUSJo92q4/c3AhOnnsERI33XHKuFXBaUARa7vkANhsxLUjM79VsFZ7S+pWQ5sJoa EQMZc+nq7yU50GZIr2420JehPp8bPW/qjJAwx6ax+ajSt+DKRhWHIeHxuT4sy1KVOGox DXYyLUr277lAa0clnLEEDOchzoTMLY+sTZIR7iOq+efxsd1rAqIkUVE1ctVm2fegjs/y MuRi+aSG+33nSarxyPPokLgcepd7Wjy6OADMQfwi+00Dp7xIxCZkD+c7vMQ4oTPobAsL MYmVCuK+5jYquJ/al3xyv+yAbKW969DLpW8lI6OOEVgTFo1OVOgw8YuMsLaPjVSBDkcB 8/XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=9PKvEIM8WmNeF102fR+24mnayrzo1xxoEPx0MZrNWjo=; b=OkE15nDRF9lXKbbKtx4LXkut1PiBy2a+69bGSOcBsH6tH9eT61drT8fp5s5VhnrkWZ rlmaXPImuowtlD7SsWtEt/IadtWmm47LwvCdSISDosw5Xa2JsJm2gchwCbtoGHmcwdf+ tZmehOPvUKLytWhAtv0T1yuTj2r8s0VNsv24GN3K1A+hAWR/uJxtYnK96ZQc0IUhSfP4 FSknJCgJndAkrKHfe7k9RuqwrxC6yZookvuQdZx1cP6UkPudk6TySl11jzQig7r5Hx70 15mTysHSZN5zRfX6avt/f/t9oj5PLfMr4qYn0pqsl2FLgoJngNSzeyry00s0yCENwEjy yuGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i78si8801214pfi.150.2018.01.19.00.26.14; Fri, 19 Jan 2018 00:26:29 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755152AbeASIZc (ORCPT + 99 others); Fri, 19 Jan 2018 03:25:32 -0500 Received: from mx2.suse.de ([195.135.220.15]:35414 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754881AbeASIZT (ORCPT ); Fri, 19 Jan 2018 03:25:19 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 34F82ACDB; Fri, 19 Jan 2018 08:25:18 +0000 (UTC) Date: Fri, 19 Jan 2018 09:25:17 +0100 From: Michal Hocko To: "He, Roger" Cc: "Grodzovsky, Andrey" , "linux-mm@kvack.org" , "amd-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "Koenig, Christian" Subject: Re: [RFC] Per file OOM badness Message-ID: <20180119082517.GM6584@dhcp22.suse.cz> References: <1516294072-17841-1-git-send-email-andrey.grodzovsky@amd.com> <20180118170006.GG6584@dhcp22.suse.cz> <20180118171355.GH6584@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [removed the broken quoting - please try to use an email client which doesn't mess up the qouted text] On Fri 19-01-18 06:01:26, He, Roger wrote: [...] > I think you are misunderstanding here. > Actually for now, the memory in TTM Pools already has mm_shrink which is implemented in ttm_pool_mm_shrink_init. > And here the memory we want to make it contribute to OOM badness is not in TTM Pools. > Because when TTM buffer allocation success, the memory already is removed from TTM Pools. I have no idea what TTM buffers are. But this smells like something rather specific to the particular subsytem. And my main objection here is that struct file is not a proper vehicle to carry such an information. So whatever the TTM subsystem does it should contribute to generic counters rather than abuse fd because it happens to use it to communicate with userspace. -- Michal Hocko SUSE Labs