From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751713AbeA3L2m (ORCPT ); Tue, 30 Jan 2018 06:28:42 -0500 Received: from mail-wm0-f54.google.com ([74.125.82.54]:39654 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751619AbeA3L2k (ORCPT ); Tue, 30 Jan 2018 06:28:40 -0500 X-Google-Smtp-Source: AH8x2276rdrkMo5I+bcmypCaHKu5Qo76+cepeDLNDv2nSOWG1fto+dCmHr0cuZVkKHNXit2vGxBCFQ== Reply-To: christian.koenig@amd.com Subject: Re: [RFC] Per file OOM badness To: =?UTF-8?Q?Michel_D=c3=a4nzer?= , =?UTF-8?Q?Christian_K=c3=b6nig?= , Michal Hocko , Roman Gushchin Cc: linux-mm@kvack.org, amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org References: <20180118170006.GG6584@dhcp22.suse.cz> <20180123152659.GA21817@castle.DHCP.thefacebook.com> <20180123153631.GR1526@dhcp22.suse.cz> <20180124092847.GI1526@dhcp22.suse.cz> <583f328e-ff46-c6a4-8548-064259995766@daenzer.net> <20180124110141.GA28465@dhcp22.suse.cz> <36b49523-792d-45f9-8617-32b6d9d77418@daenzer.net> <20180124115059.GC28465@dhcp22.suse.cz> <381a868c-78fd-d0d1-029e-a2cf4ab06d37@gmail.com> <20180130093145.GE25930@phenom.ffwll.local> <3db43c1a-59b8-af86-2b87-c783c629f512@daenzer.net> <3026d8c5-9313-cb8b-91ef-09c02baf27db@amd.com> <445628d3-677c-a9f8-171f-7d74a603c61d@daenzer.net> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Tue, 30 Jan 2018 12:28:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <445628d3-677c-a9f8-171f-7d74a603c61d@daenzer.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 30.01.2018 um 12:02 schrieb Michel Dänzer: > On 2018-01-30 11:40 AM, Christian König wrote: >> Am 30.01.2018 um 10:43 schrieb Michel Dänzer: >>> [SNIP] >>>> Would it be ok to hang onto potentially arbitrary mmget references >>>> essentially forever? If that's ok I think we can do your process based >>>> account (minus a few minor inaccuracies for shared stuff perhaps, but no >>>> one cares about that). >>> Honestly, I think you and Christian are overthinking this. Let's try >>> charging the memory to every process which shares a buffer, and go from >>> there. >> My problem is that this needs to be bullet prove. >> >> For example imagine an application which allocates a lot of BOs, then >> calls fork() and let the parent process die. The file descriptor lives >> on in the child process, but the memory is not accounted against the child. > What exactly are you referring to by "the file descriptor" here? The file descriptor used to identify the connection to the driver. In other words our drm_file structure in the kernel. > What happens to BO handles in general in this case? If both parent and > child process keep the same handle for the same BO, one of them > destroying the handle will result in the other one not being able to use > it anymore either, won't it? Correct. That usage is actually not useful at all, but we already had applications which did exactly that by accident. Not to mention that somebody could do it on purpose. Regards, Christian. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f197.google.com (mail-wr0-f197.google.com [209.85.128.197]) by kanga.kvack.org (Postfix) with ESMTP id BD9156B0005 for ; Tue, 30 Jan 2018 06:28:40 -0500 (EST) Received: by mail-wr0-f197.google.com with SMTP id a63so8005191wrc.15 for ; Tue, 30 Jan 2018 03:28:40 -0800 (PST) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id b36sor6476623ede.7.2018.01.30.03.28.38 for (Google Transport Security); Tue, 30 Jan 2018 03:28:39 -0800 (PST) Reply-To: christian.koenig@amd.com Subject: Re: [RFC] Per file OOM badness References: <20180118170006.GG6584@dhcp22.suse.cz> <20180123152659.GA21817@castle.DHCP.thefacebook.com> <20180123153631.GR1526@dhcp22.suse.cz> <20180124092847.GI1526@dhcp22.suse.cz> <583f328e-ff46-c6a4-8548-064259995766@daenzer.net> <20180124110141.GA28465@dhcp22.suse.cz> <36b49523-792d-45f9-8617-32b6d9d77418@daenzer.net> <20180124115059.GC28465@dhcp22.suse.cz> <381a868c-78fd-d0d1-029e-a2cf4ab06d37@gmail.com> <20180130093145.GE25930@phenom.ffwll.local> <3db43c1a-59b8-af86-2b87-c783c629f512@daenzer.net> <3026d8c5-9313-cb8b-91ef-09c02baf27db@amd.com> <445628d3-677c-a9f8-171f-7d74a603c61d@daenzer.net> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Tue, 30 Jan 2018 12:28:37 +0100 MIME-Version: 1.0 In-Reply-To: <445628d3-677c-a9f8-171f-7d74a603c61d@daenzer.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: owner-linux-mm@kvack.org List-ID: To: =?UTF-8?Q?Michel_D=c3=a4nzer?= , =?UTF-8?Q?Christian_K=c3=b6nig?= , Michal Hocko , Roman Gushchin Cc: linux-mm@kvack.org, amd-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Am 30.01.2018 um 12:02 schrieb Michel DA?nzer: > On 2018-01-30 11:40 AM, Christian KA?nig wrote: >> Am 30.01.2018 um 10:43 schrieb Michel DA?nzer: >>> [SNIP] >>>> Would it be ok to hang onto potentially arbitrary mmget references >>>> essentially forever? If that's ok I think we can do your process based >>>> account (minus a few minor inaccuracies for shared stuff perhaps, but no >>>> one cares about that). >>> Honestly, I think you and Christian are overthinking this. Let's try >>> charging the memory to every process which shares a buffer, and go from >>> there. >> My problem is that this needs to be bullet prove. >> >> For example imagine an application which allocates a lot of BOs, then >> calls fork() and let the parent process die. The file descriptor lives >> on in the child process, but the memory is not accounted against the child. > What exactly are you referring to by "the file descriptor" here? The file descriptor used to identify the connection to the driver. In other words our drm_file structure in the kernel. > What happens to BO handles in general in this case? If both parent and > child process keep the same handle for the same BO, one of them > destroying the handle will result in the other one not being able to use > it anymore either, won't it? Correct. That usage is actually not useful at all, but we already had applications which did exactly that by accident. Not to mention that somebody could do it on purpose. Regards, Christian. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org