From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751833AbeA3JnR (ORCPT ); Tue, 30 Jan 2018 04:43:17 -0500 Received: from mail.netline.ch ([148.251.143.178]:41800 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751801AbeA3JnN (ORCPT ); Tue, 30 Jan 2018 04:43:13 -0500 Subject: Re: [RFC] Per file OOM badness To: christian.koenig@amd.com, Michal Hocko , dri-devel@lists.freedesktop.org, Roman Gushchin 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> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, amd-gfx@lists.freedesktop.org Message-ID: <3db43c1a-59b8-af86-2b87-c783c629f512@daenzer.net> Date: Tue, 30 Jan 2018 10:43:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180130093145.GE25930@phenom.ffwll.local> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-01-30 10:31 AM, Daniel Vetter wrote: > On Wed, Jan 24, 2018 at 01:11:09PM +0100, Christian König wrote: >> Am 24.01.2018 um 12:50 schrieb Michal Hocko: >>> On Wed 24-01-18 12:23:10, Michel Dänzer wrote: >>>> On 2018-01-24 12:01 PM, Michal Hocko wrote: >>>>> On Wed 24-01-18 11:27:15, Michel Dänzer wrote: >>> [...] >>>>>> 2. If the OOM killer kills a process which is sharing BOs with another >>>>>> process, this should result in the other process dropping its references >>>>>> to the BOs as well, at which point the memory is released. >>>>> OK. How exactly are those BOs mapped to the userspace? >>>> I'm not sure what you're asking. Userspace mostly uses a GEM handle to >>>> refer to a BO. There can also be userspace CPU mappings of the BO's >>>> memory, but userspace doesn't need CPU mappings for all BOs and only >>>> creates them as needed. >>> OK, I guess you have to bear with me some more. This whole stack is a >>> complete uknonwn. I am mostly after finding a boundary where you can >>> charge the allocated memory to the process so that the oom killer can >>> consider it. Is there anything like that? Except for the proposed file >>> handle hack? >> >> Not that I knew of. >> >> As I said before we need some kind of callback that a process now starts to >> use a file descriptor, but without anything from that file descriptor mapped >> into the address space. > > For more context: With DRI3 and wayland the compositor opens the DRM fd > and then passes it to the client, which then starts allocating stuff. That > makes book-keeping rather annoying. Actually, what you're describing is only true for the buffers shared by an X server with an X11 compositor. For the actual applications, the buffers are created on the client side and then shared with the X server / Wayland compositor. Anyway, it doesn't really matter. In all cases, the buffers are actually used by all parties that are sharing them, so charging the memory to all of them is perfectly appropriate. > I guess a good first order approximation would be if we simply charge any > newly allocated buffers to the process that created them, but that means > hanging onto lots of mm_struct pointers since we want to make sure we then > release those pages to the right mm again (since the process that drops > the last ref might be a totally different one, depending upon how the > buffers or DRM fd have been shared). > > 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. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) by kanga.kvack.org (Postfix) with ESMTP id 582EB6B0006 for ; Tue, 30 Jan 2018 04:43:14 -0500 (EST) Received: by mail-lf0-f69.google.com with SMTP id m200so3995819lfg.2 for ; Tue, 30 Jan 2018 01:43:14 -0800 (PST) Received: from netline-mail3.netline.ch (mail.netline.ch. [148.251.143.178]) by mx.google.com with ESMTP id f8si6197485lfa.42.2018.01.30.01.43.12 for ; Tue, 30 Jan 2018 01:43:12 -0800 (PST) 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> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: <3db43c1a-59b8-af86-2b87-c783c629f512@daenzer.net> Date: Tue, 30 Jan 2018 10:43:10 +0100 MIME-Version: 1.0 In-Reply-To: <20180130093145.GE25930@phenom.ffwll.local> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: christian.koenig@amd.com, Michal Hocko , dri-devel@lists.freedesktop.org, Roman Gushchin Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, amd-gfx@lists.freedesktop.org On 2018-01-30 10:31 AM, Daniel Vetter wrote: > On Wed, Jan 24, 2018 at 01:11:09PM +0100, Christian KA?nig wrote: >> Am 24.01.2018 um 12:50 schrieb Michal Hocko: >>> On Wed 24-01-18 12:23:10, Michel DA?nzer wrote: >>>> On 2018-01-24 12:01 PM, Michal Hocko wrote: >>>>> On Wed 24-01-18 11:27:15, Michel DA?nzer wrote: >>> [...] >>>>>> 2. If the OOM killer kills a process which is sharing BOs with another >>>>>> process, this should result in the other process dropping its references >>>>>> to the BOs as well, at which point the memory is released. >>>>> OK. How exactly are those BOs mapped to the userspace? >>>> I'm not sure what you're asking. Userspace mostly uses a GEM handle to >>>> refer to a BO. There can also be userspace CPU mappings of the BO's >>>> memory, but userspace doesn't need CPU mappings for all BOs and only >>>> creates them as needed. >>> OK, I guess you have to bear with me some more. This whole stack is a >>> complete uknonwn. I am mostly after finding a boundary where you can >>> charge the allocated memory to the process so that the oom killer can >>> consider it. Is there anything like that? Except for the proposed file >>> handle hack? >> >> Not that I knew of. >> >> As I said before we need some kind of callback that a process now starts to >> use a file descriptor, but without anything from that file descriptor mapped >> into the address space. > > For more context: With DRI3 and wayland the compositor opens the DRM fd > and then passes it to the client, which then starts allocating stuff. That > makes book-keeping rather annoying. Actually, what you're describing is only true for the buffers shared by an X server with an X11 compositor. For the actual applications, the buffers are created on the client side and then shared with the X server / Wayland compositor. Anyway, it doesn't really matter. In all cases, the buffers are actually used by all parties that are sharing them, so charging the memory to all of them is perfectly appropriate. > I guess a good first order approximation would be if we simply charge any > newly allocated buffers to the process that created them, but that means > hanging onto lots of mm_struct pointers since we want to make sure we then > release those pages to the right mm again (since the process that drops > the last ref might be a totally different one, depending upon how the > buffers or DRM fd have been shared). > > 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. -- Earthling Michel DA?nzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Subject: Re: [RFC] Per file OOM badness Date: Tue, 30 Jan 2018 10:43:10 +0100 Message-ID: <3db43c1a-59b8-af86-2b87-c783c629f512@daenzer.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20180130093145.GE25930-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> Content-Language: en-CA List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "amd-gfx" To: christian.koenig-5C7GfCeVMHo@public.gmane.org, Michal Hocko , dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Roman Gushchin Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org List-Id: dri-devel@lists.freedesktop.org T24gMjAxOC0wMS0zMCAxMDozMSBBTSwgRGFuaWVsIFZldHRlciB3cm90ZToKPiBPbiBXZWQsIEph biAyNCwgMjAxOCBhdCAwMToxMTowOVBNICswMTAwLCBDaHJpc3RpYW4gS8O2bmlnIHdyb3RlOgo+ PiBBbSAyNC4wMS4yMDE4IHVtIDEyOjUwIHNjaHJpZWIgTWljaGFsIEhvY2tvOgo+Pj4gT24gV2Vk IDI0LTAxLTE4IDEyOjIzOjEwLCBNaWNoZWwgRMOkbnplciB3cm90ZToKPj4+PiBPbiAyMDE4LTAx LTI0IDEyOjAxIFBNLCBNaWNoYWwgSG9ja28gd3JvdGU6Cj4+Pj4+IE9uIFdlZCAyNC0wMS0xOCAx MToyNzoxNSwgTWljaGVsIETDpG56ZXIgd3JvdGU6Cj4+PiBbLi4uXQo+Pj4+Pj4gMi4gSWYgdGhl IE9PTSBraWxsZXIga2lsbHMgYSBwcm9jZXNzIHdoaWNoIGlzIHNoYXJpbmcgQk9zIHdpdGggYW5v dGhlcgo+Pj4+Pj4gcHJvY2VzcywgdGhpcyBzaG91bGQgcmVzdWx0IGluIHRoZSBvdGhlciBwcm9j ZXNzIGRyb3BwaW5nIGl0cyByZWZlcmVuY2VzCj4+Pj4+PiB0byB0aGUgQk9zIGFzIHdlbGwsIGF0 IHdoaWNoIHBvaW50IHRoZSBtZW1vcnkgaXMgcmVsZWFzZWQuCj4+Pj4+IE9LLiBIb3cgZXhhY3Rs eSBhcmUgdGhvc2UgQk9zIG1hcHBlZCB0byB0aGUgdXNlcnNwYWNlPwo+Pj4+IEknbSBub3Qgc3Vy ZSB3aGF0IHlvdSdyZSBhc2tpbmcuIFVzZXJzcGFjZSBtb3N0bHkgdXNlcyBhIEdFTSBoYW5kbGUg dG8KPj4+PiByZWZlciB0byBhIEJPLiBUaGVyZSBjYW4gYWxzbyBiZSB1c2Vyc3BhY2UgQ1BVIG1h cHBpbmdzIG9mIHRoZSBCTydzCj4+Pj4gbWVtb3J5LCBidXQgdXNlcnNwYWNlIGRvZXNuJ3QgbmVl ZCBDUFUgbWFwcGluZ3MgZm9yIGFsbCBCT3MgYW5kIG9ubHkKPj4+PiBjcmVhdGVzIHRoZW0gYXMg bmVlZGVkLgo+Pj4gT0ssIEkgZ3Vlc3MgeW91IGhhdmUgdG8gYmVhciB3aXRoIG1lIHNvbWUgbW9y ZS4gVGhpcyB3aG9sZSBzdGFjayBpcyBhCj4+PiBjb21wbGV0ZSB1a25vbnduLiBJIGFtIG1vc3Rs eSBhZnRlciBmaW5kaW5nIGEgYm91bmRhcnkgd2hlcmUgeW91IGNhbgo+Pj4gY2hhcmdlIHRoZSBh bGxvY2F0ZWQgbWVtb3J5IHRvIHRoZSBwcm9jZXNzIHNvIHRoYXQgdGhlIG9vbSBraWxsZXIgY2Fu Cj4+PiBjb25zaWRlciBpdC4gSXMgdGhlcmUgYW55dGhpbmcgbGlrZSB0aGF0PyBFeGNlcHQgZm9y IHRoZSBwcm9wb3NlZCBmaWxlCj4+PiBoYW5kbGUgaGFjaz8KPj4KPj4gTm90IHRoYXQgSSBrbmV3 IG9mLgo+Pgo+PiBBcyBJIHNhaWQgYmVmb3JlIHdlIG5lZWQgc29tZSBraW5kIG9mIGNhbGxiYWNr IHRoYXQgYSBwcm9jZXNzIG5vdyBzdGFydHMgdG8KPj4gdXNlIGEgZmlsZSBkZXNjcmlwdG9yLCBi dXQgd2l0aG91dCBhbnl0aGluZyBmcm9tIHRoYXQgZmlsZSBkZXNjcmlwdG9yIG1hcHBlZAo+PiBp bnRvIHRoZSBhZGRyZXNzIHNwYWNlLgo+IAo+IEZvciBtb3JlIGNvbnRleHQ6IFdpdGggRFJJMyBh bmQgd2F5bGFuZCB0aGUgY29tcG9zaXRvciBvcGVucyB0aGUgRFJNIGZkCj4gYW5kIHRoZW4gcGFz c2VzIGl0IHRvIHRoZSBjbGllbnQsIHdoaWNoIHRoZW4gc3RhcnRzIGFsbG9jYXRpbmcgc3R1ZmYu IFRoYXQKPiBtYWtlcyBib29rLWtlZXBpbmcgcmF0aGVyIGFubm95aW5nLgoKQWN0dWFsbHksIHdo YXQgeW91J3JlIGRlc2NyaWJpbmcgaXMgb25seSB0cnVlIGZvciB0aGUgYnVmZmVycyBzaGFyZWQg YnkKYW4gWCBzZXJ2ZXIgd2l0aCBhbiBYMTEgY29tcG9zaXRvci4gRm9yIHRoZSBhY3R1YWwgYXBw bGljYXRpb25zLCB0aGUKYnVmZmVycyBhcmUgY3JlYXRlZCBvbiB0aGUgY2xpZW50IHNpZGUgYW5k IHRoZW4gc2hhcmVkIHdpdGggdGhlIFggc2VydmVyCi8gV2F5bGFuZCBjb21wb3NpdG9yLgoKQW55 d2F5LCBpdCBkb2Vzbid0IHJlYWxseSBtYXR0ZXIuIEluIGFsbCBjYXNlcywgdGhlIGJ1ZmZlcnMg YXJlIGFjdHVhbGx5CnVzZWQgYnkgYWxsIHBhcnRpZXMgdGhhdCBhcmUgc2hhcmluZyB0aGVtLCBz byBjaGFyZ2luZyB0aGUgbWVtb3J5IHRvIGFsbApvZiB0aGVtIGlzIHBlcmZlY3RseSBhcHByb3By aWF0ZS4KCgo+IEkgZ3Vlc3MgYSBnb29kIGZpcnN0IG9yZGVyIGFwcHJveGltYXRpb24gd291bGQg YmUgaWYgd2Ugc2ltcGx5IGNoYXJnZSBhbnkKPiBuZXdseSBhbGxvY2F0ZWQgYnVmZmVycyB0byB0 aGUgcHJvY2VzcyB0aGF0IGNyZWF0ZWQgdGhlbSwgYnV0IHRoYXQgbWVhbnMKPiBoYW5naW5nIG9u dG8gbG90cyBvZiBtbV9zdHJ1Y3QgcG9pbnRlcnMgc2luY2Ugd2Ugd2FudCB0byBtYWtlIHN1cmUg d2UgdGhlbgo+IHJlbGVhc2UgdGhvc2UgcGFnZXMgdG8gdGhlIHJpZ2h0IG1tIGFnYWluIChzaW5j ZSB0aGUgcHJvY2VzcyB0aGF0IGRyb3BzCj4gdGhlIGxhc3QgcmVmIG1pZ2h0IGJlIGEgdG90YWxs eSBkaWZmZXJlbnQgb25lLCBkZXBlbmRpbmcgdXBvbiBob3cgdGhlCj4gYnVmZmVycyBvciBEUk0g ZmQgaGF2ZSBiZWVuIHNoYXJlZCkuCj4gCj4gV291bGQgaXQgYmUgb2sgdG8gaGFuZyBvbnRvIHBv dGVudGlhbGx5IGFyYml0cmFyeSBtbWdldCByZWZlcmVuY2VzCj4gZXNzZW50aWFsbHkgZm9yZXZl cj8gSWYgdGhhdCdzIG9rIEkgdGhpbmsgd2UgY2FuIGRvIHlvdXIgcHJvY2VzcyBiYXNlZAo+IGFj Y291bnQgKG1pbnVzIGEgZmV3IG1pbm9yIGluYWNjdXJhY2llcyBmb3Igc2hhcmVkIHN0dWZmIHBl cmhhcHMsIGJ1dCBubwo+IG9uZSBjYXJlcyBhYm91dCB0aGF0KS4KCkhvbmVzdGx5LCBJIHRoaW5r IHlvdSBhbmQgQ2hyaXN0aWFuIGFyZSBvdmVydGhpbmtpbmcgdGhpcy4gTGV0J3MgdHJ5CmNoYXJn aW5nIHRoZSBtZW1vcnkgdG8gZXZlcnkgcHJvY2VzcyB3aGljaCBzaGFyZXMgYSBidWZmZXIsIGFu ZCBnbyBmcm9tCnRoZXJlLgoKCi0tIApFYXJ0aGxpbmcgTWljaGVsIETDpG56ZXIgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgaHR0cDovL3d3dy5hbWQuY29tCkxpYnJlIHNvZnR3YXJlIGVu dGh1c2lhc3QgICAgICAgICAgICAgfCAgICAgICAgICAgICBNZXNhIGFuZCBYIGRldmVsb3Blcgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwphbWQtZ2Z4IG1h aWxpbmcgbGlzdAphbWQtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FtZC1nZngK