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 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.