Received: by 10.223.176.46 with SMTP id f43csp920928wra; Fri, 19 Jan 2018 04:15:37 -0800 (PST) X-Google-Smtp-Source: ACJfBotBERQJh474isMIS+gb73g3kcg6BvNwT1vjsOwyEXCLWabS1CMDD0UlNdsxFkNtUVNwffMp X-Received: by 10.101.74.71 with SMTP id a7mr23644804pgu.32.1516364137223; Fri, 19 Jan 2018 04:15:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516364137; cv=none; d=google.com; s=arc-20160816; b=Gve7U0w3alGEOXjniEjIsi21KpiO0AerLw8x+44W4eRZoiYbRni/UISwXGUULH7InP NA9g61hYyH9Qe7rWAQOWWL6nxOxTZn3YHgDOar14p3Cl/+yFYuRi8szEqKy47wKmKefz M05ta/Ih1Z9cqBD1Aehj6pfL7aoWLK79/gC/INaTjqvK2/aP2QhNhFRLINuOWSDFGuME CKdGlywKMz8K8co5Q7ZiGCDVxx2C9E8C4INTPMWXccdz0XQFLouXsySEtPvLh3RbtqUY /7U9CaBL9BWDv15ThkYENwNBHksu3wy8lCvQ7uapMZBEJLUb4MjDLDZw6S3vy8/O3noG 8A6w== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=p+ijEyMgWCtIZQtm6rRaP1YJwEBHg+qIFr3cksrtcIY=; b=u9sImQXK7qRn6bs7cHXUfU7r9mfrCST6B8dlBer8wI6+P07U1yyznCMPp1ZlT6p9sg c3pDyx2zKvakHFOsR0ioyXfqzWkaLvDW7PILjR23w7Mkodj+iwRw1XwxDEeYGmlKy7sX bJ12NU4k4hoApyuEyz7g0frkrmZ1DFyA/MTmVCpyD8J6cNGWTYRSsUzBb1Wl3zei0WiD rTMAwXQCSPy+jGQ9/h28g2Z85kCToaJ25qpI6dx2v/cCpM5D9Q/S3MX0DM3scCZkglZ+ wjf3L35tfGcLBcwcJpcAqelv6z2oR+dG1Q0cEc7iPc7GdfkQereLikB4NmyJ0oZJ2LzF tNyw== 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 k131si8299252pgc.145.2018.01.19.04.15.22; Fri, 19 Jan 2018 04:15:37 -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 S1754855AbeASMOA (ORCPT + 99 others); Fri, 19 Jan 2018 07:14:00 -0500 Received: from mx2.suse.de ([195.135.220.15]:53632 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752153AbeASMNx (ORCPT ); Fri, 19 Jan 2018 07:13:53 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0C9A7ABD0; Fri, 19 Jan 2018 12:13:52 +0000 (UTC) Date: Fri, 19 Jan 2018 13:13:51 +0100 From: Michal Hocko To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Eric Anholt , Andrey Grodzovsky , linux-kernel@vger.kernel.org, linux-mm@kvack.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org Subject: Re: [RFC] Per file OOM badness Message-ID: <20180119121351.GW6584@dhcp22.suse.cz> References: <1516294072-17841-1-git-send-email-andrey.grodzovsky@amd.com> <20180118170006.GG6584@dhcp22.suse.cz> <20180118171355.GH6584@dhcp22.suse.cz> <87k1wfgcmb.fsf@anholt.net> <20180119082046.GL6584@dhcp22.suse.cz> <0cfaf256-928c-4cb8-8220-b8992592071b@amd.com> <20180119104058.GU6584@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 On Fri 19-01-18 12:37:51, Christian K?nig wrote: [...] > The per file descriptor badness is/was just the much easier approach to > solve the issue, because the drivers already knew which client is currently > using which buffer objects. > > I of course agree that file descriptors can be shared between processes and > are by themselves not killable. But at least for our graphics driven use > case I don't see much of a problem killing all processes when a file > descriptor is used by more than one at the same time. Ohh, I absolutely see why you have chosen this way for your particular usecase. I am just arguing that this would rather be more generic to be merged. If there is absolutely no other way around we can consider it but right now I do not see that all other options have been considered properly. Especially when the fd based approach is basically wrong for almost anybody else. -- Michal Hocko SUSE Labs