All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Daniel Vetter <daniel@ffwll.ch>,
	"Bhardwaj, Rajneesh" <rajneesh.bhardwaj@amd.com>
Cc: daniel.vetter@ffwll.ch, Felix Kuehling <felix.kuehling@amd.com>,
	dri-devel@lists.freedesktop.org,
	David Yat Sin <david.yatsin@amd.com>,
	amd-gfx@lists.freedesktop.org, alexander.deucher@amd.com,
	airlied@redhat.com
Subject: Re: [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process
Date: Thu, 23 Dec 2021 08:05:50 +0100	[thread overview]
Message-ID: <a5c769fd-7eac-2628-a36d-fedddfb7d398@amd.com> (raw)
In-Reply-To: <YcOQN/l7W66W/X0f@phenom.ffwll.local>

Am 22.12.21 um 21:53 schrieb Daniel Vetter:
> On Mon, Dec 20, 2021 at 01:12:51PM -0500, Bhardwaj, Rajneesh wrote:
>
> [SNIP]
> Still sounds funky. I think minimally we should have an ack from CRIU
> developers that this is officially the right way to solve this problem. I
> really don't want to have random one-off hacks that don't work across the
> board, for a problem where we (drm subsystem) really shouldn't be the only
> one with this problem. Where "this problem" means that the mmap space is
> per file description, and not per underlying inode or real device or
> whatever. That part sounds like a CRIU problem, and I expect CRIU folks
> want a consistent solution across the board for this. Hence please grab an
> ack from them.

Unfortunately it's a KFD design problem. AMD used a single device node, 
then mmaped different objects from the same offset to different 
processes and expected it to work the rest of the fs subsystem without 
churn.

So yes, this is indeed because the mmap space is per file descriptor for 
the use case here.

And thanks for pointing this out, this indeed makes the whole change 
extremely questionable.

Regards,
Christian.

>
> Cheers, Daniel
>


  parent reply	other threads:[~2021-12-23  7:06 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08 20:53 [PATCH] drm/ttm: Don't inherit GEM object VMAs in child process Rajneesh Bhardwaj
2021-12-09  7:54 ` Christian König
2021-12-09 15:23   ` Bhardwaj, Rajneesh
2021-12-09 15:27     ` Christian König
2021-12-09 15:29       ` Bhardwaj, Rajneesh
2021-12-09 15:30         ` Christian König
2021-12-09 18:28           ` Felix Kuehling
2021-12-10  6:58             ` Christian König
2021-12-20  9:29               ` Daniel Vetter
2021-12-20 18:12                 ` Bhardwaj, Rajneesh
2021-12-22 20:53                   ` Daniel Vetter
2021-12-22 20:53                     ` Daniel Vetter
2021-12-23  1:49                     ` Bhardwaj, Rajneesh
2021-12-23  1:51                       ` Bhardwaj, Rajneesh
2021-12-23  7:05                     ` Christian König [this message]
2022-01-04 18:08                       ` Felix Kuehling
2022-01-05  8:08                         ` Christian König
2022-01-05 16:16                           ` Felix Kuehling
2022-01-05 16:27                             ` Felix Kuehling
2022-01-06  9:05                             ` Christian König
2022-01-06 16:45                               ` Felix Kuehling
2022-01-06 16:48                                 ` Christian König
2022-01-06 16:51                                   ` Felix Kuehling
2022-01-07  8:56                                     ` Christian König
2022-01-07 17:47                                       ` Felix Kuehling
2022-01-14 16:44                                         ` Daniel Vetter
2022-01-14 16:44                                           ` Daniel Vetter
2022-01-14 17:26                                           ` Christian König
2022-01-14 17:40                                             ` Felix Kuehling
2022-01-17 11:44                                               ` Christian König
2022-01-17 14:17                                                 ` Felix Kuehling
2022-01-17 14:21                                                   ` Christian König
2022-01-17 14:34                                                     ` Felix Kuehling
2022-01-17 14:50                                                       ` Marek Olšák
2022-01-17 14:50                                                         ` Marek Olšák
2022-01-17 16:23                                                         ` Christian König
2022-01-17 16:23                                                           ` Christian König
2022-01-10 17:30                         ` Bhardwaj, Rajneesh

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=a5c769fd-7eac-2628-a36d-fedddfb7d398@amd.com \
    --to=christian.koenig@amd.com \
    --cc=airlied@redhat.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=david.yatsin@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=felix.kuehling@amd.com \
    --cc=rajneesh.bhardwaj@amd.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.