linux-kernel - Re: kmap_atomic_pfn for PCI BAR access?

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 7 Jul 2008 21:19:10 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Dave Airlie <airlied@...il.com>,
	Keith Packard <keithp@...thp.com>,
	Dave Airlie <airlied@...ux.ie>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: kmap_atomic_pfn for PCI BAR access?

On Monday 07 July 2008 17:05, Arjan van de Ven wrote:
> On Mon, 7 Jul 2008 16:53:54 +1000

> > One thing I still haven't implemented in that patch are CPU-local
> > mappings (which only require a local flush to flush)... I found that
> > after the improvements I did implement, they didn't help much for
> > my workloads, so I suspect you might find the same thing...
>
> just to complicate things with ioremap() you have to deal with the
> various caching-coherency requirements.. making things lazy and per CPU
> complicates that a ton (and I suspect won't actually make things
> cheaper)

Yeah, my vmap rewrite has a vm_unmap_aliases() call, which the
page attribute code calls.

But these flushes are not really any different between the atomic
kmap area and my vmap lazy flushing: the atomic kmap code still
has to do a broadcast global TLB flush.

The fact is simply that changing cache attributes is always going
to be an expensive operation and lazy mappings are not going to
really change that -- because changing attributes is going to
require a TLB flush on all CPUs _anyway_, which is the expensive
thing. All we really have to do with lazy mappings is tear down
their page tables before CPA's TLB flush -- if there were no lazy
unmappings in that time, then there will be no extra work to do.

... or, it occurs to me that you might have been referring to
something else: the problem of simply changing the cache attributes
on the pages that you wish to ioremap now. That's going to be slow
sure, but these guys don't seem to need such an attribute change
anyway because they are using kmap_atomic_pfn (which doesn't change
attributes)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/