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] [day] [month] [year] [list]

Message-Id: <1222187562.4424.47.camel@vonnegut.anholt.net>
Date:	Tue, 23 Sep 2008 09:32:42 -0700
From:	Eric Anholt <eric@...olt.net>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	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 Mon, 2008-09-22 at 10:59 -0700, Jesse Barnes wrote:
> On Wednesday, August 27, 2008 5:22 pm Nick Piggin wrote:
> > > 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.
> >
> > It can cut the cost quite significantly on normal vmap/vunmap loads I
> > tested. Whether it will work as well on your workload, I don't know
> > but I would have liked to find out. I raised this issue quite a while
> > back, so I'm disappointed it had not been tried...
> 
> I think Eric has code with the vmap changes now?
> 
> Given our discussions at KS/Plumbers would you be ok with acking these 
> patches?  Or do you want a repost so you can check out the vmap stuff?
> 
> After talking a bit more about it, I think we agreed that the ioctl interface 
> is actually a better approach then trying to shoehorn this stuff into system 
> calls, so aside from the vmap code (which could be done in 2.6.29 or whenever 
> the vmap stuff lands) I think this patchset is pretty close to what we want 
> in drm-next now...

I've been trying to get a good test of the vmap changes.  Unfortunately,
it looks like things have changed in ioremap in the intervening time
between when I last tested and now.  I was taking 2.6.27-rc5-mm1 (since
that was the only git tree I found with Nick's changes in it,
unfortunately) and merging our stuff into there then reverting the
kmap_atomic_prot_pfn bit.

However, we've moved from 10% cost in unmapping due to IPIing to a >30%
cost in mapping due to change_page_attr.  This is regardless of whether
I do ioremap or ioremap_wc.  The physical range is covered by a WC MTRR,
and the X Server's mapping the memory using the _wc resource.  In the
DRM, I just tried moving every ioremap to _wc, and it's the same.  The
call chain looks like

i915_gem_pwrite_ioctl (60%)
ioremap_wc (39%)
ioremap_nocache (39%)
ioremap_caller (39%)
ioremap_change_attr (36%)
_set_memory_uc (36%)
change_page_attr_set_clr (36%)
vm_unmap_aliases (31%)

Maybe if I go back and generate a tree of just Nick's changes and try to
merge them forward I can get a good test.  However, it looks to me like
we've got some serious brokenness in ioremap and attribute handling
coming up.

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

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