From: Daniel Vetter <daniel@ffwll.ch>
To: Christoph Hellwig <hch@lst.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
intel-gfx@lists.freedesktop.org,
Chris Wilson <chris@chris-wilson.co.uk>,
linux-mm@kvack.org, dri-devel@lists.freedesktop.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Intel-gfx] add remap_pfn_range_notrack instead of reinventing it in i915
Date: Mon, 1 Mar 2021 10:13:36 +0100 [thread overview]
Message-ID: <YDywQBl/Lw5OTKE2@phenom.ffwll.local> (raw)
In-Reply-To: <20210301084559.GA29133@lst.de>
On Mon, Mar 01, 2021 at 09:45:59AM +0100, Christoph Hellwig wrote:
> On Mon, Mar 01, 2021 at 09:44:13AM +0100, Daniel Vetter wrote:
> > On Mon, Mar 01, 2021 at 09:33:18AM +0100, Christoph Hellwig wrote:
> > > Hi all,
> > >
> > > i915 has some reason to want to avoid the track_pfn_remap overhead in
> > > remap_pfn_range. Add a function to the core VM to do just that rather
> > > than reinventing the functionality poorly in the driver.
> >
> > It's not _notrack it's "rely on the tracking established by the struct
> > io_mapping". Exporting a _notrack version to drivers sounds like not
> > something we want to ever do. So I think you want a helper which takes the
> > io_mapping, and not something that encourages drivers to go full stupid.
>
> As far as I can tell there is no struct io_mapping anywhere near
> remap_io_sg.
Yeah that looks like real bad taste, but it is how this stuff is (or at
least was, been years I've followed this closely) meant to work. Comment
in the code still claims it's the way:
/* We rely on prevalidation of the io-mapping to skip track_pfn(). */
If that's a lie and there's no iomapping for that range, then ugh.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-03-01 9:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 8:33 [Intel-gfx] add remap_pfn_range_notrack instead of reinventing it in i915 Christoph Hellwig
2021-03-01 8:33 ` [Intel-gfx] [PATCH 1/2] mm: add remap_pfn_range_notrack Christoph Hellwig
2021-03-01 8:33 ` [Intel-gfx] [PATCH 2/2] i915: use remap_pfn_range_notrack Christoph Hellwig
2021-03-01 8:44 ` [Intel-gfx] add remap_pfn_range_notrack instead of reinventing it in i915 Daniel Vetter
2021-03-01 8:45 ` Christoph Hellwig
2021-03-01 9:13 ` Daniel Vetter [this message]
2021-03-01 8:53 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] mm: add remap_pfn_range_notrack Patchwork
2021-03-01 8:56 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-03-01 9:24 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
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=YDywQBl/Lw5OTKE2@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=akpm@linux-foundation.org \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.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;
as well as URLs for NNTP newsgroup(s).