From: Joerg Roedel <joro@8bytes.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Jani Nikula <jani.nikula@linux.intel.com>,
David Airlie <airlied@linux.ie>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: mmu_notifier and i915_gem_userptr.c
Date: Thu, 19 Jun 2014 17:36:55 +0200 [thread overview]
Message-ID: <20140619153655.GG31771@8bytes.org> (raw)
Hey Chris,
recently I had a look at i915_gem_userptr.c in order to extend the
mmu_notifier call-backs implemented there. My goal is to implement the
change_pte call-back where it is necessary to get rid of it being
wrapped mn_invalidate_range_start/end() calls (for the reason see
commit 6bdb913f).
For most users of mmu_notifiers this is easy, except the i915 driver :)
The invalidate_range_start notifier implemented there can sleep, so it
can't be reused for a change_pte implementation (because change_pte is
called under ptl spin_lock and is not allowed to sleep). On the other
hand you also didn't implement the invalidate_page notifier, so I am not
sure whether the code actually cares about the somewhat similar
change_pte events?
Here is where change_pte is called from:
* In KSM code when pages are merged (shouldn't be relevant
because KSM doesn't merged pages returned by get_user_pages())
* In uprobes code when a user-page is replaced by a kernel page
(should only handle .text sections, so probaly not relevant
here)
* When someone writes to a COW page in mm/memory.c (this looks
relevant looking at forked processes, on the other hand,
this is currently handled by unbinding the vma from the
object list in the i915 driver)
I am not familiar with the i915 hardware and the driver implementation
details, so I wanted to ask whether the driver
1) Cares about the change_pte event?
2) If it cares, what is the best way to implement it? What the
invalidate_range_start() notifier does seems a bit overkill,
since for the change_pte event nothing is unmapped (but maybe
remapped)
So any insight you could provide here would be useful :)
Thanks,
Joerg
next reply other threads:[~2014-06-19 15:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-19 15:36 Joerg Roedel [this message]
2014-06-19 16:02 ` mmu_notifier and i915_gem_userptr.c Chris Wilson
2014-06-19 16:02 ` Chris Wilson
2014-06-20 11:43 ` Joerg Roedel
2014-06-20 11:43 ` Joerg Roedel
2014-06-25 22:18 ` Joerg Roedel
2014-06-25 22:18 ` Joerg Roedel
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=20140619153655.GG31771@8bytes.org \
--to=joro@8bytes.org \
--cc=airlied@linux.ie \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=linux-kernel@vger.kernel.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.