From: Christoph Hellwig <hch@lst.de>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Christoph Hellwig <hch@lst.de>,
Matthew Wilcox <willy@infradead.org>,
Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>,
linux-mm@kvack.org, Peter Zijlstra <peterz@infradead.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Minchan Kim <minchan@kernel.org>,
dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org,
Andrew Morton <akpm@linux-foundation.org>,
intel-gfx@lists.freedesktop.org, Nitin Gupta <ngupta@vflare.org>,
Chris Wilson <chris@chris-wilson.co.uk>,
Matthew Auld <matthew.auld@intel.com>
Subject: Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
Date: Wed, 23 Sep 2020 08:11:02 +0200 [thread overview]
Message-ID: <20200923061102.GA15762@lst.de> (raw)
In-Reply-To: <1b05b9d6-a14c-85cd-0728-d0d40c9ff84b@linux.intel.com>
On Tue, Sep 22, 2020 at 06:04:37PM +0100, Tvrtko Ursulin wrote:
> Only reason I can come up with now is if mapping side is on a latency
> sensitive path, while un-mapping is lazy/delayed so can be more costly.
> Then fast map and extra cost on unmap may make sense.
In general yes. But compared to the overall operations a small kmalloc
is in the noise, so I'd really like to see numbers.
> It more applies to the other i915 patch, which implements a much more used
> API, but whether or not we can demonstrate any difference in the perf
> profiles I couldn't tell you without trying to collect some.
The other patch keeps the stack, as avoiding it would not simplify the
code as significantly. I still doubt it is all that useful, though.
>> We could do vmalloc_to_page, but that is fairly expensive (not as bad
>> as reading from the page cache..). Are you really worried about the
>> allocation?
>
> Not so much given how we don't even use shmem_pin_map outside selftests.
>
> If we start using it I expect it will be for tiny objects anyway. Only if
> they end up being pinned for the lifetime of the driver, it may be a
> pointless waste of memory compared to the downsides of vmalloc_to_page. But
> we can revisit this particular edge case optimization if the need arises.
For tiny object we could either look into using kmap, or in fact
ensure the shmem files aren't in highmem, in which case you could
always use single-page mappings without any extra mapping.
next prev parent reply other threads:[~2020-09-23 6:11 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 16:37 remove alloc_vm_area Christoph Hellwig
2020-09-18 16:37 ` [PATCH 1/6] zsmalloc: switch from alloc_vm_area to get_vm_area Christoph Hellwig
2020-09-21 17:42 ` Minchan Kim
2020-09-21 18:17 ` Christoph Hellwig
2020-09-21 18:42 ` Minchan Kim
2020-09-21 18:43 ` Christoph Hellwig
2020-09-18 16:37 ` [PATCH 2/6] mm: add a vmap_pfn function Christoph Hellwig
2020-09-18 16:37 ` [PATCH 3/6] drm/i915: use vmap in shmem_pin_map Christoph Hellwig
2020-09-21 19:11 ` Matthew Wilcox
2020-09-22 6:22 ` Christoph Hellwig
2020-09-22 8:23 ` [Intel-gfx] " Tvrtko Ursulin
2020-09-22 14:31 ` Christoph Hellwig
2020-09-22 16:13 ` Tvrtko Ursulin
2020-09-22 16:33 ` Christoph Hellwig
2020-09-22 17:04 ` Tvrtko Ursulin
2020-09-23 6:11 ` Christoph Hellwig [this message]
2020-09-22 11:21 ` Matthew Wilcox
2020-09-22 14:39 ` Christoph Hellwig
2020-09-22 14:53 ` Matthew Wilcox
2020-09-18 16:37 ` [PATCH 4/6] drm/i915: use vmap in i915_gem_object_map Christoph Hellwig
2020-09-23 9:52 ` [Intel-gfx] " Tvrtko Ursulin
2020-09-23 13:41 ` Christoph Hellwig
2020-09-23 13:58 ` Tvrtko Ursulin
2020-09-23 14:44 ` Christoph Hellwig
2020-09-24 12:22 ` Tvrtko Ursulin
2020-09-24 13:23 ` Christoph Hellwig
2020-09-18 16:37 ` [PATCH 5/6] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv Christoph Hellwig
2020-09-18 16:37 ` [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc Christoph Hellwig
2020-09-21 20:44 ` boris.ostrovsky
2020-09-22 14:58 ` Christoph Hellwig
2020-09-22 15:24 ` boris.ostrovsky
2020-09-22 15:27 ` Christoph Hellwig
2020-09-22 15:34 ` boris.ostrovsky
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=20200923061102.GA15762@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=boris.ostrovsky@oracle.com \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.auld@intel.com \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=peterz@infradead.org \
--cc=sstabellini@kernel.org \
--cc=tvrtko.ursulin@linux.intel.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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).