From: Joerg Roedel <jroedel@suse.de>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Oded Gabbay <oded.gabbay@amd.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mm: export find_extend_vma and handle_mm_fault for driver use
Date: Thu, 6 Nov 2014 14:01:22 +0100 [thread overview]
Message-ID: <20141106130122.GJ8354@suse.de> (raw)
In-Reply-To: <20141105135109.39ea54fe@jbarnes-hsw>
On Wed, Nov 05, 2014 at 01:51:09PM -0800, Jesse Barnes wrote:
> On Wed, 5 Nov 2014 13:03:51 +0100
> Joerg Roedel <jroedel@suse.de> wrote:
> > Thanks for testing Oded. Jesse, the patch looks good to me, except the
> > task accounting for the page-faults. I'd like to get rid of using
> > task_struct in the IOMMUv2 driver entirely if possible. Also it is not
> > really the CPU task causing the faults, but some non-CPU process.
>
> Hm, but the CPU task initiates the activity on the GPU, so we should
> account for it somewhere, right? I guess I had been thinking of the
> "task" as spanning the CPUs and GPUs and other devices in the system,
> rather than just representing the CPU activity.
One problem is that the task that called amd_iommu_bind_pasid() isn't
necessarily the same task (thread) that queues the jobs to the device.
The thread that called amd_iommu_bind_pasid() might even exit while
other threads still use the mappings.
Besides that, from an abstract point of view, what is running on the
device (GPU) is a logically seperate 'thread' of the process which we
should account for seperatly. If we want accounting for these off-CPU
threads we should probably introduce some concept of a non-CPU task to
the kernel and do the accounting there?
Joerg
next prev parent reply other threads:[~2014-11-06 13:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 19:34 [PATCH 1/2] mm: export find_extend_vma and handle_mm_fault for driver use Jesse Barnes
2014-10-24 19:34 ` [PATCH 2/2] iommu/amd: use handle_mm_fault directly Jesse Barnes
2014-10-27 15:13 ` [PATCH 1/2] mm: export find_extend_vma and handle_mm_fault for driver use Joerg Roedel
2014-10-27 15:15 ` Oded Gabbay
2014-10-27 15:35 ` Jesse Barnes
2014-10-27 15:37 ` Oded Gabbay
2014-10-29 9:33 ` Oded Gabbay
2014-10-29 14:37 ` Jesse Barnes
2014-11-05 12:03 ` Joerg Roedel
2014-11-05 21:51 ` Jesse Barnes
2014-11-06 8:51 ` Oded Gabbay
2014-11-06 13:03 ` Joerg Roedel
2014-11-06 13:01 ` Joerg Roedel [this message]
2014-11-12 22:07 ` Jesse Barnes
2014-11-17 16:53 ` Joerg Roedel
-- strict thread matches above, loose matches on Subject: below --
2014-11-12 22:10 Jesse Barnes
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=20141106130122.GJ8354@suse.de \
--to=jroedel@suse.de \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oded.gabbay@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.