From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754841AbeASISB (ORCPT ); Fri, 19 Jan 2018 03:18:01 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:40124 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753529AbeASIRy (ORCPT ); Fri, 19 Jan 2018 03:17:54 -0500 X-Google-Smtp-Source: ACJfBovFaJ6yStTcRjKwl99ppNpD4bu/3TttzwwpY2xStxCe40IOd8HLSax7CDJWSwzYF31tsrzmZg== Reply-To: christian.koenig@amd.com Subject: Re: [RFC] Per file OOM badness To: "He, Roger" , "Grodzovsky, Andrey" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "dri-devel@lists.freedesktop.org" , "amd-gfx@lists.freedesktop.org" Cc: "Koenig, Christian" References: <1516294072-17841-1-git-send-email-andrey.grodzovsky@amd.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <78121ca2-3693-d43e-5a5f-989380fb3667@gmail.com> Date: Fri, 19 Jan 2018 09:17:51 +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: 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 19.01.2018 um 06:39 schrieb He, Roger: > Basically the idea is right to me. > > 1. But we need smaller granularity to control the contribution to OOM badness. > Because when the TTM buffer resides in VRAM rather than evict to system memory, we should not take this account into badness. > But I think it is not easy to implement. I was considering that as well when I wrote the original patch set, but then decided against it at least for now. Basically all VRAM buffers can be swapped to system memory, so they potentially need system memory as well. That is especially important during suspend/resume. > > 2. If the TTM buffer(GTT here) is mapped to user for CPU access, not quite sure the buffer size is already taken into account for kernel. > If yes, at last the size will be counted again by your patches. No that isn't accounted for as far as I know. > > So, I am thinking if we can counted the TTM buffer size into: > struct mm_rss_stat { > atomic_long_t count[NR_MM_COUNTERS]; > }; > Which is done by kernel based on CPU VM (page table). > > Something like that: > When GTT allocate suceess: > add_mm_counter(vma->vm_mm, MM_ANONPAGES, buffer_size); > > When GTT swapped out: > dec_mm_counter from MM_ANONPAGES frist, then > add_mm_counter(vma->vm_mm, MM_SWAPENTS, buffer_size); // or MM_SHMEMPAGES or add new item. > > Update the corresponding item in mm_rss_stat always. > If that, we can control the status update accurately. > What do you think about that? > And is there any side-effect for this approach? I already tried this when I originally worked on the issue and that approach didn't worked because allocated buffers are not associated to the process where they are created. E.g. most display surfaces are created by the X server, but used by processes. So if you account the BO to the process who created it we would start to kill X again and that is exactly what we try to avoid. Regards, Christian. > > > Thanks > Roger(Hongbo.He) > > -----Original Message----- > From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of Andrey Grodzovsky > Sent: Friday, January 19, 2018 12:48 AM > To: linux-kernel@vger.kernel.org; linux-mm@kvack.org; dri-devel@lists.freedesktop.org; amd-gfx@lists.freedesktop.org > Cc: Koenig, Christian > Subject: [RFC] Per file OOM badness > > Hi, this series is a revised version of an RFC sent by Christian König a few years ago. The original RFC can be found at https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html > > This is the same idea and I've just adressed his concern from the original RFC and switched to a callback into file_ops instead of a new member in struct file. > > Thanks, > Andrey > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f71.google.com (mail-wm0-f71.google.com [74.125.82.71]) by kanga.kvack.org (Postfix) with ESMTP id D0D576B0253 for ; Fri, 19 Jan 2018 03:17:54 -0500 (EST) Received: by mail-wm0-f71.google.com with SMTP id k126so687164wmd.5 for ; Fri, 19 Jan 2018 00:17:54 -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 y22sor5382931edm.12.2018.01.19.00.17.53 for (Google Transport Security); Fri, 19 Jan 2018 00:17:53 -0800 (PST) Reply-To: christian.koenig@amd.com Subject: Re: [RFC] Per file OOM badness References: <1516294072-17841-1-git-send-email-andrey.grodzovsky@amd.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: <78121ca2-3693-d43e-5a5f-989380fb3667@gmail.com> Date: Fri, 19 Jan 2018 09:17:51 +0100 MIME-Version: 1.0 In-Reply-To: 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: "He, Roger" , "Grodzovsky, Andrey" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "dri-devel@lists.freedesktop.org" , "amd-gfx@lists.freedesktop.org" Cc: "Koenig, Christian" Am 19.01.2018 um 06:39 schrieb He, Roger: > Basically the idea is right to me. > > 1. But we need smaller granularity to control the contribution to OOM badness. > Because when the TTM buffer resides in VRAM rather than evict to system memory, we should not take this account into badness. > But I think it is not easy to implement. I was considering that as well when I wrote the original patch set, but then decided against it at least for now. Basically all VRAM buffers can be swapped to system memory, so they potentially need system memory as well. That is especially important during suspend/resume. > > 2. If the TTM buffer(GTT here) is mapped to user for CPU access, not quite sure the buffer size is already taken into account for kernel. > If yes, at last the size will be counted again by your patches. No that isn't accounted for as far as I know. > > So, I am thinking if we can counted the TTM buffer size into: > struct mm_rss_stat { > atomic_long_t count[NR_MM_COUNTERS]; > }; > Which is done by kernel based on CPU VM (page table). > > Something like that: > When GTT allocate suceess: > add_mm_counter(vma->vm_mm, MM_ANONPAGES, buffer_size); > > When GTT swapped out: > dec_mm_counter from MM_ANONPAGES frist, then > add_mm_counter(vma->vm_mm, MM_SWAPENTS, buffer_size); // or MM_SHMEMPAGES or add new item. > > Update the corresponding item in mm_rss_stat always. > If that, we can control the status update accurately. > What do you think about that? > And is there any side-effect for this approach? I already tried this when I originally worked on the issue and that approach didn't worked because allocated buffers are not associated to the process where they are created. E.g. most display surfaces are created by the X server, but used by processes. So if you account the BO to the process who created it we would start to kill X again and that is exactly what we try to avoid. Regards, Christian. > > > Thanks > Roger(Hongbo.He) > > -----Original Message----- > From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of Andrey Grodzovsky > Sent: Friday, January 19, 2018 12:48 AM > To: linux-kernel@vger.kernel.org; linux-mm@kvack.org; dri-devel@lists.freedesktop.org; amd-gfx@lists.freedesktop.org > Cc: Koenig, Christian > Subject: [RFC] Per file OOM badness > > Hi, this series is a revised version of an RFC sent by Christian KA?nig a few years ago. The original RFC can be found at https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html > > This is the same idea and I've just adressed his concern from the original RFC and switched to a callback into file_ops instead of a new member in struct file. > > Thanks, > Andrey > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx -- 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?Christian_K=c3=b6nig?= Subject: Re: [RFC] Per file OOM badness Date: Fri, 19 Jan 2018 09:17:51 +0100 Message-ID: <78121ca2-3693-d43e-5a5f-989380fb3667@gmail.com> References: <1516294072-17841-1-git-send-email-andrey.grodzovsky@amd.com> Reply-To: christian.koenig@amd.com Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: "He, Roger" , "Grodzovsky, Andrey" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "dri-devel@lists.freedesktop.org" , "amd-gfx@lists.freedesktop.org" Cc: "Koenig, Christian" List-Id: dri-devel@lists.freedesktop.org QW0gMTkuMDEuMjAxOCB1bSAwNjozOSBzY2hyaWViIEhlLCBSb2dlcjoKPiBCYXNpY2FsbHkgdGhl IGlkZWEgaXMgcmlnaHQgdG8gbWUuCj4KPiAxLiBCdXQgd2UgbmVlZCBzbWFsbGVyIGdyYW51bGFy aXR5IHRvIGNvbnRyb2wgdGhlIGNvbnRyaWJ1dGlvbiB0byBPT00gYmFkbmVzcy4KPiAgICAgICBC ZWNhdXNlIHdoZW4gdGhlIFRUTSBidWZmZXIgcmVzaWRlcyBpbiBWUkFNIHJhdGhlciB0aGFuIGV2 aWN0IHRvIHN5c3RlbSBtZW1vcnksIHdlIHNob3VsZCBub3QgdGFrZSB0aGlzIGFjY291bnQgaW50 byBiYWRuZXNzLgo+ICAgICAgIEJ1dCBJIHRoaW5rIGl0IGlzIG5vdCBlYXN5IHRvIGltcGxlbWVu dC4KCkkgd2FzIGNvbnNpZGVyaW5nIHRoYXQgYXMgd2VsbCB3aGVuIEkgd3JvdGUgdGhlIG9yaWdp bmFsIHBhdGNoIHNldCwgYnV0IAp0aGVuIGRlY2lkZWQgYWdhaW5zdCBpdCBhdCBsZWFzdCBmb3Ig bm93LgoKQmFzaWNhbGx5IGFsbCBWUkFNIGJ1ZmZlcnMgY2FuIGJlIHN3YXBwZWQgdG8gc3lzdGVt IG1lbW9yeSwgc28gdGhleSAKcG90ZW50aWFsbHkgbmVlZCBzeXN0ZW0gbWVtb3J5IGFzIHdlbGwu IFRoYXQgaXMgZXNwZWNpYWxseSBpbXBvcnRhbnQgCmR1cmluZyBzdXNwZW5kL3Jlc3VtZS4KCj4K PiAyLiBJZiB0aGUgVFRNIGJ1ZmZlcihHVFQgaGVyZSkgaXMgbWFwcGVkIHRvIHVzZXIgZm9yIENQ VSBhY2Nlc3MsIG5vdCBxdWl0ZSBzdXJlIHRoZSBidWZmZXIgc2l6ZSBpcyBhbHJlYWR5IHRha2Vu IGludG8gYWNjb3VudCBmb3Iga2VybmVsLgo+ICAgICAgIElmIHllcywgYXQgbGFzdCB0aGUgc2l6 ZSB3aWxsIGJlIGNvdW50ZWQgYWdhaW4gYnkgeW91ciBwYXRjaGVzLgoKTm8gdGhhdCBpc24ndCBh Y2NvdW50ZWQgZm9yIGFzIGZhciBhcyBJIGtub3cuCgo+Cj4gU28sIEkgYW0gdGhpbmtpbmcgaWYg d2UgY2FuIGNvdW50ZWQgdGhlIFRUTSBidWZmZXIgc2l6ZSBpbnRvOgo+IHN0cnVjdCBtbV9yc3Nf c3RhdCB7Cj4gCWF0b21pY19sb25nX3QgY291bnRbTlJfTU1fQ09VTlRFUlNdOwo+IH07Cj4gV2hp Y2ggaXMgZG9uZSBieSBrZXJuZWwgYmFzZWQgb24gQ1BVIFZNIChwYWdlIHRhYmxlKS4KPgo+IFNv bWV0aGluZyBsaWtlIHRoYXQ6Cj4gV2hlbiBHVFQgYWxsb2NhdGUgc3VjZWVzczoKPiBhZGRfbW1f Y291bnRlcih2bWEtPnZtX21tLCBNTV9BTk9OUEFHRVMsIGJ1ZmZlcl9zaXplKTsKPgo+IFdoZW4g R1RUIHN3YXBwZWQgb3V0Ogo+IGRlY19tbV9jb3VudGVyIGZyb20gTU1fQU5PTlBBR0VTIGZyaXN0 LCB0aGVuCj4gYWRkX21tX2NvdW50ZXIodm1hLT52bV9tbSwgTU1fU1dBUEVOVFMsIGJ1ZmZlcl9z aXplKTsgIC8vIG9yIE1NX1NITUVNUEFHRVMgb3IgYWRkIG5ldyBpdGVtLgo+Cj4gVXBkYXRlIHRo ZSBjb3JyZXNwb25kaW5nIGl0ZW0gaW4gbW1fcnNzX3N0YXQgYWx3YXlzLgo+IElmIHRoYXQsIHdl IGNhbiBjb250cm9sIHRoZSBzdGF0dXMgdXBkYXRlIGFjY3VyYXRlbHkuCj4gV2hhdCBkbyB5b3Ug dGhpbmsgYWJvdXQgdGhhdD8KPiBBbmQgaXMgdGhlcmUgYW55IHNpZGUtZWZmZWN0IGZvciB0aGlz IGFwcHJvYWNoPwoKSSBhbHJlYWR5IHRyaWVkIHRoaXMgd2hlbiBJIG9yaWdpbmFsbHkgd29ya2Vk IG9uIHRoZSBpc3N1ZSBhbmQgdGhhdCAKYXBwcm9hY2ggZGlkbid0IHdvcmtlZCBiZWNhdXNlIGFs bG9jYXRlZCBidWZmZXJzIGFyZSBub3QgYXNzb2NpYXRlZCB0byAKdGhlIHByb2Nlc3Mgd2hlcmUg dGhleSBhcmUgY3JlYXRlZC4KCkUuZy4gbW9zdCBkaXNwbGF5IHN1cmZhY2VzIGFyZSBjcmVhdGVk IGJ5IHRoZSBYIHNlcnZlciwgYnV0IHVzZWQgYnkgCnByb2Nlc3Nlcy4gU28gaWYgeW91IGFjY291 bnQgdGhlIEJPIHRvIHRoZSBwcm9jZXNzIHdobyBjcmVhdGVkIGl0IHdlIAp3b3VsZCBzdGFydCB0 byBraWxsIFggYWdhaW4gYW5kIHRoYXQgaXMgZXhhY3RseSB3aGF0IHdlIHRyeSB0byBhdm9pZC4K ClJlZ2FyZHMsCkNocmlzdGlhbi4KCj4KPgo+IFRoYW5rcwo+IFJvZ2VyKEhvbmdiby5IZSkKPgo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gRnJvbTogZHJpLWRldmVsIFttYWlsdG86ZHJp LWRldmVsLWJvdW5jZXNAbGlzdHMuZnJlZWRlc2t0b3Aub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmV5 IEdyb2R6b3Zza3kKPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMTksIDIwMTggMTI6NDggQU0KPiBU bzogbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXgtbW1Aa3ZhY2sub3JnOyBkcmkt ZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnOyBhbWQtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9y Zwo+IENjOiBLb2VuaWcsIENocmlzdGlhbiA8Q2hyaXN0aWFuLktvZW5pZ0BhbWQuY29tPgo+IFN1 YmplY3Q6IFtSRkNdIFBlciBmaWxlIE9PTSBiYWRuZXNzCj4KPiBIaSwgdGhpcyBzZXJpZXMgaXMg YSByZXZpc2VkIHZlcnNpb24gb2YgYW4gUkZDIHNlbnQgYnkgQ2hyaXN0aWFuIEvDtm5pZyBhIGZl dyB5ZWFycyBhZ28uIFRoZSBvcmlnaW5hbCBSRkMgY2FuIGJlIGZvdW5kIGF0IGh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL2FyY2hpdmVzL2RyaS1kZXZlbC8yMDE1LVNlcHRlbWJlci8wODk3 NzguaHRtbAo+Cj4gVGhpcyBpcyB0aGUgc2FtZSBpZGVhIGFuZCBJJ3ZlIGp1c3QgYWRyZXNzZWQg aGlzIGNvbmNlcm4gZnJvbSB0aGUgb3JpZ2luYWwgUkZDIGFuZCBzd2l0Y2hlZCB0byBhIGNhbGxi YWNrIGludG8gZmlsZV9vcHMgaW5zdGVhZCBvZiBhIG5ldyBtZW1iZXIgaW4gc3RydWN0IGZpbGUu Cj4KPiBUaGFua3MsCj4gQW5kcmV5Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+IGRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKPiBkcmktZGV2ZWxAbGlz dHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1h bi9saXN0aW5mby9kcmktZGV2ZWwKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+IGFtZC1nZnggbWFpbGluZyBsaXN0Cj4gYW1kLWdmeEBsaXN0cy5mcmVl ZGVza3RvcC5vcmcKPiBodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2FtZC1nZngKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9y ZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZl bAo=