linux-kernel - Re: [PATCH] Export kmap_atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1219855961.4994.6.camel@vonnegut.anholt.net>
Date:	Wed, 27 Aug 2008 09:52:41 -0700
From:	Eric Anholt <eric@...olt.net>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	Dave Airlie <airlied@...il.com>, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Export kmap_atomic_pfn for DRM-GEM.

On Wed, 2008-08-27 at 23:36 +1000, Nick Piggin wrote:
> On Wednesday 27 August 2008 05:43, Eric Anholt wrote:
> > The driver would like to map IO space directly for copying data in when
> > appropriate, to avoid CPU cache flushing for streaming writes.
> > kmap_atomic_pfn lets us avoid IPIs associated with ioremap for this
> > process.
> >
> > Signed-off-by: Eric Anholt <eric@...olt.net>
> > ---
> >  arch/x86/mm/highmem_32.c |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c
> > index 165c871..d52e91d 100644
> > --- a/arch/x86/mm/highmem_32.c
> > +++ b/arch/x86/mm/highmem_32.c
> > @@ -137,6 +137,7 @@ void *kmap_atomic_pfn(unsigned long pfn, enum km_type
> > type)
> >
> >  	return (void*) vaddr;
> >  }
> > +EXPORT_SYMBOL(kmap_atomic_pfn);
> >
> >  struct page *kmap_atomic_to_page(void *ptr)
> >  {
> 
> 
> I wonder if you ever tested my vmap rework patches with this issue? It
> seems somewhat x86 specific and also not conceptually so clean to use
> kmap_atomic_pfn for this. vmap may not be used by all architectures but
> I think it might be able to cover some of them.
> 
> As I said, there are some other possible improvements that can be made
> to my vmap rewrite if performance isn't good enough, but I simply have
> not seen numbers...

The consumer of this is a driver for Intel platforms, so being
x86-specific is not a worry this patch series.

However, when other DRM drivers get around to doing memory management,
I'm sure they'll also be interested in an ioremap_wc that doesn't eat
ipi costs.  For us, the ipis for flushing were eating over 10% of CPU
time.  If your patch series cuts that cost, we could drop this piece at
that point.

-- 
Eric Anholt
eric@...olt.net                         eric.anholt@...el.com



Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)