From: Andrew Morton <akpm@linux-foundation.org>
To: Keith Packard <keithp@keithp.com>
Cc: mingo@elte.hu, keithp@keithp.com, nickpiggin@yahoo.com.au,
airlied@linux.ie, torvalds@linux-foundation.org,
linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
dri-devel@lists.sf.net, yinghai@kernel.org
Subject: Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
Date: Thu, 23 Oct 2008 13:38:40 -0700 [thread overview]
Message-ID: <20081023133840.d4eef579.akpm@linux-foundation.org> (raw)
In-Reply-To: <1224793332.22877.8.camel@koto.keithp.com>
On Thu, 23 Oct 2008 13:22:12 -0700
Keith Packard <keithp@keithp.com> wrote:
> We just ran some numbers on a box with PAT enabled and broken MTRRs.
> Finally we have a test platform for the difference between kmap_atomic
> and kmap_atomic_prot. Using regular kmap_atomic on this platform, we get
> UC access to the graphics device; sending data from the CPU is a bit
> slow. Adding kmap_atomic_prot_pfn and specifying WC access raises that
> by a fairly significant factor, taking our CPU utilization for
> copy_from_user from 40% to 2%.
>
> Here's a patch which adds kmap_atomic_prot_pfn to the kernel for this
> usage. When we add native io-mapping support instead of sitting on top
> of kmap, we can remove this function.
>
> I've reworked the io_mapping patches to use this function as well, along
> with cleaning up the i915 code along the lines of Linus' current
> version. I'll post those if this patch looks acceptable.
>
> From e3f633dcb36889fa85ea06cca339072df3c44ae0 Mon Sep 17 00:00:00 2001
> From: Keith Packard <keithp@keithp.com>
> Date: Thu, 23 Oct 2008 11:53:45 -0700
> Subject: [PATCH] Add kmap_atomic_prot_pfn
>
> kmap_atomic_prot_pfn is a mixture of kmap_atomic_prot and kmap_atomic_pfn,
> accepting both a pfn instead of a page and an explicit protection value.
>
> Signed-off-by: Keith Packard <keithp@keithp.com>
> ---
> arch/x86/mm/highmem_32.c | 19 +++++++++++++++++++
> include/asm-x86/highmem.h | 1 +
> include/linux/highmem.h | 1 +
> 3 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c
> index bcc079c..91ae5e8 100644
> --- a/arch/x86/mm/highmem_32.c
> +++ b/arch/x86/mm/highmem_32.c
> @@ -139,6 +139,25 @@ void *kmap_atomic_pfn(unsigned long pfn, enum km_type type)
> }
> EXPORT_SYMBOL_GPL(kmap_atomic_pfn); /* temporarily in use by i915 GEM until vmap */
>
> +/* This is the same as kmap_atomic_prot() but can map memory that doesn't
> + * have a struct page associated with it.
> + */
> +void *kmap_atomic_prot_pfn(unsigned long pfn, enum km_type type, pgprot_t prot)
> +{
> + enum fixed_addresses idx;
> + unsigned long vaddr;
> +
> + pagefault_disable();
> +
> + idx = type + KM_TYPE_NR*smp_processor_id();
> + vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
> + set_pte(kmap_pte-idx, pfn_pte(pfn, prot));
> + arch_flush_lazy_mmu_mode();
> +
> + return (void*) vaddr;
> +}
> +EXPORT_SYMBOL_GPL(kmap_atomic_prot_pfn); /* temporarily in use by i915 GEM until vmap */
I guess one could reimplemenet kmap_atomic_pfn() to call this. Sometime.
> struct page *kmap_atomic_to_page(void *ptr)
> {
> unsigned long idx, vaddr = (unsigned long)ptr;
> diff --git a/include/asm-x86/highmem.h b/include/asm-x86/highmem.h
> index bc3f6a2..a1f8f8c 100644
> --- a/include/asm-x86/highmem.h
> +++ b/include/asm-x86/highmem.h
> @@ -66,6 +66,7 @@ void *kmap_atomic_prot(struct page *page, enum km_type type, pgprot_t prot);
> void *kmap_atomic(struct page *page, enum km_type type);
> void kunmap_atomic(void *kvaddr, enum km_type type);
> void *kmap_atomic_pfn(unsigned long pfn, enum km_type type);
> +void *kmap_atomic_prot_pfn(unsigned long pfn, enum km_type type, pgprot_t prot);
Given that all highmem-implementing archtiectures must use the same
declaration here, we might as well put it into include/linux/highmem.h.
Although that goes against current mistakes^Wcode.
Does powerpc32 still implement highmem? It seems that way. You broke
it, no?
next prev parent reply other threads:[~2008-10-23 20:40 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-17 21:29 [git pull] drm patches for 2.6.27-rc1 Dave Airlie
2008-10-17 22:43 ` Linus Torvalds
2008-10-18 2:10 ` Eric Anholt
2008-10-18 2:47 ` Linus Torvalds
2008-10-18 3:49 ` Keith Packard
2008-10-18 6:44 ` Corbin Simpson
2008-10-18 7:49 ` Eric Anholt
2008-10-19 17:52 ` Peter Zijlstra
2008-10-20 4:17 ` Steven J Newbury
2008-10-20 16:31 ` Linus Torvalds
2008-10-20 20:04 ` Jesse Barnes
2008-10-18 9:11 ` Dave Airlie
2008-10-18 1:37 ` Nick Piggin
2008-10-18 19:11 ` Keith Packard
2008-10-18 19:31 ` Linus Torvalds
2008-10-18 20:07 ` Thomas Hellström
2008-10-18 20:20 ` Keith Packard
2008-10-18 20:37 ` Ingo Molnar
2008-10-18 21:51 ` Keith Packard
2008-10-18 22:32 ` Ingo Molnar
2008-10-18 22:47 ` Jon Smirl
2008-10-18 22:53 ` Linus Torvalds
2008-10-19 0:38 ` Keith Packard
2008-10-19 1:06 ` Arjan van de Ven
2008-10-19 1:15 ` Keith Packard
2008-10-20 10:01 ` Ingo Molnar
2008-10-19 4:14 ` Keith Packard
2008-10-19 6:41 ` Keith Packard
2008-10-19 17:53 ` io resources and cached mappings (was: [git pull] drm patches for 2.6.27-rc1) Ingo Molnar
2008-10-19 18:00 ` Arjan van de Ven
2008-10-19 19:07 ` Eric Anholt
2008-10-20 11:55 ` Ingo Molnar
2008-10-20 12:20 ` Ingo Molnar
2008-10-19 21:04 ` Keith Packard
2008-10-20 11:58 ` Ingo Molnar
2008-10-20 15:49 ` Keith Packard
2008-10-22 9:36 ` Ingo Molnar
2008-10-23 7:14 ` Keith Packard
2008-10-23 7:14 ` [PATCH] Add io-mapping functions to dynamically map large device apertures Keith Packard
2008-10-23 7:14 ` [PATCH] [drm/i915] Use io-mapping interfaces instead of a variety of mapping kludges Keith Packard
2008-10-24 4:49 ` [PATCH] Add io-mapping functions to dynamically map large device apertures Randy Dunlap
2008-10-24 6:26 ` Keith Packard
2008-10-23 8:05 ` io resources and cached mappings (was: [git pull] drm patches for 2.6.27-rc1) Ingo Molnar
2008-10-23 15:39 ` Keith Packard
2008-11-03 7:00 ` Dave Airlie
2008-11-03 10:48 ` Ingo Molnar
2008-11-03 16:36 ` Linus Torvalds
2008-11-03 16:53 ` Ingo Molnar
2008-11-03 17:29 ` [git pull] IO mappings, #2 Ingo Molnar
2008-11-04 22:36 ` Jonathan Corbet
2008-11-05 9:01 ` Ingo Molnar
2008-10-23 20:22 ` Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1) Keith Packard
2008-10-23 20:38 ` Andrew Morton [this message]
2008-10-23 21:03 ` Keith Packard
2008-10-23 21:24 ` Linus Torvalds
2008-10-24 1:50 ` Keith Packard
2008-10-24 2:48 ` Linus Torvalds
2008-10-24 3:24 ` Benjamin Herrenschmidt
2008-10-24 5:37 ` Keith Packard
2008-10-24 14:53 ` Linus Torvalds
2008-10-24 15:45 ` Keith Packard
2008-10-24 4:29 ` Keith Packard
2008-10-24 6:22 ` Keith Packard
2008-10-24 7:33 ` Adding kmap_atomic_prot_pfn Thomas Hellström
2008-10-24 8:38 ` Ingo Molnar
2008-10-24 9:19 ` Thomas Hellström
2008-10-24 9:32 ` Ingo Molnar
2008-10-24 11:04 ` Thomas Hellström
2008-10-24 15:48 ` Keith Packard
2008-10-24 10:18 ` Thomas Hellström
2008-10-24 9:14 ` Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1) Ingo Molnar
2008-10-24 3:21 ` Benjamin Herrenschmidt
2008-10-20 10:10 ` io resources and cached mappings " Ingo Molnar
2008-10-19 4:28 ` [git pull] drm patches for 2.6.27-rc1 Yinghai Lu
2008-10-19 3:14 ` Nick Piggin
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=20081023133840.d4eef579.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.sf.net \
--cc=jbarnes@virtuousgeek.org \
--cc=keithp@keithp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=torvalds@linux-foundation.org \
--cc=yinghai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox