All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <j.glisse@gmail.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: "Gabbay, Oded" <Oded.Gabbay@amd.com>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"Lewycky, Andrew" <Andrew.Lewycky@amd.com>,
	"Cornwall, Jay" <Jay.Cornwall@amd.com>,
	"Bridgman, John" <John.Bridgman@amd.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mgorman@suse.de" <mgorman@suse.de>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"peterz@infraread.org" <peterz@infraread.org>,
	"aarcange@redhat.com" <aarcange@redhat.com>,
	"riel@redhat.com" <riel@redhat.com>,
	"jweiner@redhat.com" <jweiner@redhat.com>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	Mark Hairgrove <mhairgrove@nvidia.com>,
	Jatin Kumar <jakumar@nvidia.com>,
	Subhash Gutti <sgutti@nvidia.com>,
	Lucien Dunning <ldunning@nvidia.com>,
	Cameron Buschardt <cabuschardt@nvidia.com>,
	Arvind Gopalakrishnan <arvindg@nvidia.com>,
	John Hubbard <jhubbard@nvidia.com>,
	Sherry Cheung <SCheung@nvidia.com>,
	Duncan Poole <dpoole@nvidia.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>
Subject: Re: [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler.
Date: Tue, 1 Jul 2014 15:33:44 -0400	[thread overview]
Message-ID: <20140701193343.GB3322@gmail.com> (raw)
In-Reply-To: <20140701110018.GH26537@8bytes.org>

On Tue, Jul 01, 2014 at 01:00:18PM +0200, Joerg Roedel wrote:
> On Tue, Jul 01, 2014 at 09:29:49AM +0000, Gabbay, Oded wrote:
> > In the KFD, we need to maintain a notion of each compute process.
> > Therefore, we have an object called "kfd_process" that is created for
> > each process that uses the KFD. Naturally, we need to be able to track
> > the process's shutdown in order to perform cleanup of the resources it
> > uses (compute queues, virtual address space, gpu local memory
> > allocations, etc.).
> 
> If it is only that, you can also use the task_exit notifier already in
> the kernel.

No task_exit will happen per thread not once per mm.

> 
> > To enable this tracking mechanism, we decided to associate the
> > kfd_process with mm_struct to ensure that a kfd_process object has
> > exactly the same lifespan as the process it represents. We preferred to
> > use the mm_struct and not a file description because using a file
> > descriptor to track a??processa?? shutdown is wrong in two ways:
> > 
> > * Technical: file descriptors can be passed to unrelated processes using
> > AF_UNIX sockets. This means that a process can exit while the file stays
> > open. Even if we implement this a??correctlya?? i.e. holding the address
> > space & page tables alive until the file is finally released, ita??s
> > really dodgy.
> 
> No, its not in this case. The file descriptor is used to connect a
> process address space with a device context. Thus without the mappings
> the file-descriptor is useless and the mappings should stay in-tact
> until the fd is closed.
> 
> It would be a very bad semantic for userspace if a fd that is passed on
> fails on the other side because the sending process died.
> 

Consider use case where there is no file associated with the mmu_notifier
ie there is no device file descriptor that could hold and take care of
mmu_notifier destruction and cleanup. We need this call chain for this
case.

Anyother idea than task_exit ?

Cheers,
JA(C)rA'me

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <j.glisse@gmail.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: "Gabbay, Oded" <Oded.Gabbay@amd.com>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"Lewycky, Andrew" <Andrew.Lewycky@amd.com>,
	"Cornwall, Jay" <Jay.Cornwall@amd.com>,
	"Bridgman, John" <John.Bridgman@amd.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mgorman@suse.de" <mgorman@suse.de>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"peterz@infraread.org" <peterz@infraread.org>,
	"aarcange@redhat.com" <aarcange@redhat.com>,
	"riel@redhat.com" <riel@redhat.com>,
	"jweiner@redhat.com" <jweiner@redhat.com>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	Mark Hairgrove <mhairgrove@nvidia.com>,
	Jatin Kumar <jakumar@nvidia.com>,
	Subhash Gutti <sgutti@nvidia.com>,
	Lucien Dunning <ldunning@nvidia.com>,
	Cameron Buschardt <cabuschardt@nvidia.com>,
	Ar
Subject: Re: [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler.
Date: Tue, 1 Jul 2014 15:33:44 -0400	[thread overview]
Message-ID: <20140701193343.GB3322@gmail.com> (raw)
In-Reply-To: <20140701110018.GH26537@8bytes.org>

On Tue, Jul 01, 2014 at 01:00:18PM +0200, Joerg Roedel wrote:
> On Tue, Jul 01, 2014 at 09:29:49AM +0000, Gabbay, Oded wrote:
> > In the KFD, we need to maintain a notion of each compute process.
> > Therefore, we have an object called "kfd_process" that is created for
> > each process that uses the KFD. Naturally, we need to be able to track
> > the process's shutdown in order to perform cleanup of the resources it
> > uses (compute queues, virtual address space, gpu local memory
> > allocations, etc.).
> 
> If it is only that, you can also use the task_exit notifier already in
> the kernel.

No task_exit will happen per thread not once per mm.

> 
> > To enable this tracking mechanism, we decided to associate the
> > kfd_process with mm_struct to ensure that a kfd_process object has
> > exactly the same lifespan as the process it represents. We preferred to
> > use the mm_struct and not a file description because using a file
> > descriptor to track “process” shutdown is wrong in two ways:
> > 
> > * Technical: file descriptors can be passed to unrelated processes using
> > AF_UNIX sockets. This means that a process can exit while the file stays
> > open. Even if we implement this “correctly” i.e. holding the address
> > space & page tables alive until the file is finally released, it’s
> > really dodgy.
> 
> No, its not in this case. The file descriptor is used to connect a
> process address space with a device context. Thus without the mappings
> the file-descriptor is useless and the mappings should stay in-tact
> until the fd is closed.
> 
> It would be a very bad semantic for userspace if a fd that is passed on
> fails on the other side because the sending process died.
> 

Consider use case where there is no file associated with the mmu_notifier
ie there is no device file descriptor that could hold and take care of
mmu_notifier destruction and cleanup. We need this call chain for this
case.

Anyother idea than task_exit ?

Cheers,
Jérôme

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-07-01 19:33 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-28  2:00 mm preparatory patches for HMM and IOMMUv2 Jérôme Glisse
2014-06-28  2:00 ` Jérôme Glisse
2014-06-28  2:00 ` [PATCH 1/6] mmput: use notifier chain to call subsystem exit handler Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  3:49   ` John Hubbard
2014-06-30  3:49     ` John Hubbard
2014-06-30 15:07     ` Jerome Glisse
2014-06-30 15:07       ` Jerome Glisse
2014-06-30 14:41   ` Gabbay, Oded
2014-06-30 14:41     ` Gabbay, Oded
2014-06-30 15:06     ` Jerome Glisse
2014-06-30 15:06       ` Jerome Glisse
     [not found]     ` <019CCE693E457142B37B791721487FD91806B836-0nO7ALo/ziwxlywnonMhLEEOCMrvLtNR@public.gmane.org>
2014-06-30 15:40       ` Joerg Roedel
2014-06-30 16:06         ` Jerome Glisse
2014-06-30 16:06           ` Jerome Glisse
2014-06-30 18:16           ` Joerg Roedel
2014-06-30 18:16             ` Joerg Roedel
2014-06-30 18:35             ` Jerome Glisse
2014-06-30 18:35               ` Jerome Glisse
2014-06-30 18:57               ` Lewycky, Andrew
2014-06-30 18:57                 ` Lewycky, Andrew
2014-07-01  9:41                 ` Joerg Roedel
2014-07-01  9:41                   ` Joerg Roedel
     [not found]               ` <20140630183556.GB3280-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-01  9:15                 ` Joerg Roedel
2014-07-01  9:29                   ` Gabbay, Oded
2014-07-01  9:29                     ` Gabbay, Oded
     [not found]                     ` <019CCE693E457142B37B791721487FD91806DD8B-0nO7ALo/ziwxlywnonMhLEEOCMrvLtNR@public.gmane.org>
2014-07-01 11:00                       ` Joerg Roedel
2014-07-01 19:33                         ` Jerome Glisse [this message]
2014-07-01 19:33                           ` Jerome Glisse
     [not found]                           ` <20140701193343.GB3322-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-01 21:06                             ` Joerg Roedel
2014-07-01 21:32                               ` Jerome Glisse
2014-07-01 21:32                                 ` Jerome Glisse
2014-07-03 18:30                                 ` Jerome Glisse
2014-07-03 18:30                                   ` Jerome Glisse
     [not found]                                   ` <20140703183024.GA3306-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-03 23:15                                     ` Joerg Roedel
2014-07-04  0:03                                       ` Jerome Glisse
2014-07-04  0:03                                         ` Jerome Glisse
2014-07-06 19:25                                       ` Gabbay, Oded
2014-07-06 19:25                                         ` Gabbay, Oded
2014-07-07 10:11                                         ` joro
2014-07-07 10:11                                           ` joro
2014-07-07 10:36                                           ` Oded Gabbay
2014-07-07 10:36                                             ` Oded Gabbay
2014-07-07 10:43                                           ` Oded Gabbay
2014-07-07 10:43                                             ` Oded Gabbay
     [not found]                                             ` <1404729783.31606.1.camel-OrheeFI7RUaGvNAqNQFwiPZ4XP/Yx64J@public.gmane.org>
2014-07-08  8:00                                               ` joro-zLv9SwRftAIdnm+yROfE0A
2014-07-08 17:03                                                 ` Jerome Glisse
2014-07-08 17:03                                                   ` Jerome Glisse
2015-10-11 19:03                                                   ` David Woodhouse
2015-10-11 19:03                                                     ` David Woodhouse
2015-10-12 17:41                                                     ` Jerome Glisse
2015-10-12 17:41                                                       ` Jerome Glisse
2015-10-12 17:41                                                       ` Jerome Glisse
2015-11-20 15:45                                                     ` David Woodhouse
2015-11-20 15:45                                                       ` David Woodhouse
2014-06-30 15:37   ` Joerg Roedel
2014-06-28  2:00 ` [PATCH 2/6] mm: differentiate unmap for vmscan from other unmap Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  3:58   ` John Hubbard
2014-06-30  3:58     ` John Hubbard
2014-06-30 15:58     ` Jerome Glisse
2014-06-30 15:58       ` Jerome Glisse
2014-06-28  2:00 ` [PATCH 3/6] mmu_notifier: add event information to address invalidation v2 Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  5:22   ` John Hubbard
2014-06-30  5:22     ` John Hubbard
2014-06-30 15:57     ` Jerome Glisse
2014-06-30 15:57       ` Jerome Glisse
2014-07-01  1:57   ` Linus Torvalds
2014-06-28  2:00 ` [PATCH 4/6] mmu_notifier: pass through vma to invalidate_range and invalidate_page Jérôme Glisse
2014-06-28  2:00   ` Jérôme Glisse
2014-06-30  3:29   ` John Hubbard
2014-06-30  3:29     ` John Hubbard
2014-06-30 16:00     ` Jerome Glisse
2014-06-30 16:00       ` Jerome Glisse
2014-07-01  2:04   ` Linus Torvalds

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=20140701193343.GB3322@gmail.com \
    --to=j.glisse@gmail.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Andrew.Lewycky@amd.com \
    --cc=Jay.Cornwall@amd.com \
    --cc=John.Bridgman@amd.com \
    --cc=Oded.Gabbay@amd.com \
    --cc=SCheung@nvidia.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arvindg@nvidia.com \
    --cc=cabuschardt@nvidia.com \
    --cc=dpoole@nvidia.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jakumar@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=jweiner@redhat.com \
    --cc=ldunning@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhairgrove@nvidia.com \
    --cc=peterz@infraread.org \
    --cc=riel@redhat.com \
    --cc=sgutti@nvidia.com \
    --cc=torvalds@linux-foundation.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 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.