dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: "Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Christian.Koenig-5C7GfCeVMHo@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>
Subject: Re: [RFC] Per file OOM badness
Date: Wed, 24 Jan 2018 12:50:59 +0100	[thread overview]
Message-ID: <20180124115059.GC28465@dhcp22.suse.cz> (raw)
In-Reply-To: <36b49523-792d-45f9-8617-32b6d9d77418-otUistvHUpPR7s880joybQ@public.gmane.org>

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?
-- 
Michal Hocko
SUSE Labs
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2018-01-24 11:50 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-18 16:47 [RFC] Per file OOM badness Andrey Grodzovsky
2018-01-18 16:47 ` [PATCH 1/4] fs: add OOM badness callback in file_operatrations struct Andrey Grodzovsky
2018-01-18 16:47 ` [PATCH 2/4] oom: take per file badness into account Andrey Grodzovsky
     [not found] ` <1516294072-17841-1-git-send-email-andrey.grodzovsky-5C7GfCeVMHo@public.gmane.org>
2018-01-18 16:47   ` [PATCH 3/4] drm/gem: adjust per file OOM badness on handling buffers Andrey Grodzovsky
2018-01-19  6:01     ` Chunming Zhou
2018-01-18 16:47   ` [PATCH 4/4] drm/amdgpu: Use drm_oom_badness for amdgpu Andrey Grodzovsky
2018-01-30  9:24     ` Daniel Vetter
     [not found]       ` <20180130092413.GD25930-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-01-30 12:42         ` Andrey Grodzovsky
2018-01-18 17:00 ` [RFC] Per file OOM badness Michal Hocko
2018-01-18 17:13   ` Michal Hocko
2018-01-18 20:01     ` Eric Anholt
2018-01-19  8:20       ` Michal Hocko
     [not found]         ` <20180119082046.GL6584-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-01-19  8:39           ` Christian König
2018-01-19  9:32             ` Michel Dänzer
2018-01-19  9:58               ` Christian König
     [not found]                 ` <11153f4f-8b9a-5780-6087-bc1e85459584-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-19 10:02                   ` Michel Dänzer
2018-01-19 15:07                     ` Michel Dänzer
2018-01-21  6:50                       ` Eric Anholt
2018-01-19 10:40             ` Michal Hocko
2018-01-19 11:37               ` Christian König
2018-01-19 12:13                 ` Michal Hocko
2018-01-19 12:20                   ` Michal Hocko
2018-01-19 16:54                     ` Christian König
2018-01-23 11:39                       ` Michal Hocko
2018-01-19 16:48                 ` Michel Dänzer
2018-01-19  8:35       ` Christian König
2018-01-19  6:01     ` He, Roger
2018-01-19  8:25       ` Michal Hocko
2018-01-19 10:02         ` roger
2018-01-23 15:27   ` Roman Gushchin
2018-01-23 15:36     ` Michal Hocko
     [not found]       ` <20180123153631.GR1526-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-01-23 16:39         ` Michel Dänzer
2018-01-24  9:28           ` Michal Hocko
2018-01-24 10:27             ` Michel Dänzer
2018-01-24 11:01               ` Michal Hocko
2018-01-24 11:23                 ` Michel Dänzer
     [not found]                   ` <36b49523-792d-45f9-8617-32b6d9d77418-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-01-24 11:50                     ` Michal Hocko [this message]
2018-01-24 12:11                       ` Christian König
2018-01-30  9:31                         ` Daniel Vetter
     [not found]                           ` <20180130093145.GE25930-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-01-30  9:43                             ` Michel Dänzer
2018-01-30 10:40                               ` Christian König
2018-01-30 11:02                                 ` Michel Dänzer
2018-01-30 11:28                                   ` Christian König
2018-01-30 11:34                                     ` Michel Dänzer
2018-01-30 11:36                                       ` Nicolai Hähnle
2018-01-30 11:42                                         ` Michel Dänzer
2018-01-30 11:56                                           ` Christian König
2018-01-30 15:52                                             ` Michel Dänzer
2018-01-30 10:42                               ` Daniel Vetter
2018-01-30 10:48                                 ` Michel Dänzer
2018-01-30 11:35                                   ` Nicolai Hähnle
     [not found]                       ` <20180124115059.GC28465-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-01-24 14:31                         ` Michel Dänzer
2018-01-30  9:29                       ` Michel Dänzer
2018-01-30 10:28                         ` Michal Hocko
     [not found]                           ` <20180130102855.GY21609-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2018-03-26 14:36                             ` Lucas Stach
     [not found]                               ` <1522074988.1196.1.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2018-04-04  9:09                                 ` Michel Dänzer
2018-04-04  9:36                                   ` Lucas Stach
2018-04-04  9:46                                     ` Michel Dänzer
2018-01-19  5:39 ` He, Roger
2018-01-19  8:17   ` Christian König
2018-01-22 23:23 ` Andrew Morton
     [not found]   ` <20180122152315.749d88f3c91ffce4d70ac450-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2018-01-23  1:59     ` Andrey Grodzovsky
  -- strict thread matches above, loose matches on Subject: below --
2015-09-04 12:53 Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180124115059.GC28465@dhcp22.suse.cz \
    --to=mhocko-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
    --cc=Christian.Koenig-5C7GfCeVMHo@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=guro-b10kYP2dOMg@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=michel-otUistvHUpPR7s880joybQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox