Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755519AbYGGHFy (ORCPT ); Mon, 7 Jul 2008 03:05:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754013AbYGGHFq (ORCPT ); Mon, 7 Jul 2008 03:05:46 -0400 Received: from casper.infradead.org ([85.118.1.10]:33386 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbYGGHFp (ORCPT ); Mon, 7 Jul 2008 03:05:45 -0400 Date: Mon, 7 Jul 2008 00:05:28 -0700 From: Arjan van de Ven To: Nick Piggin Cc: Jeremy Fitzhardinge , Dave Airlie , Keith Packard , Dave Airlie , linux-kernel Subject: Re: kmap_atomic_pfn for PCI BAR access? Message-ID: <20080707000528.09518481@infradead.org> In-Reply-To: <200807071653.55094.nickpiggin@yahoo.com.au> References: <1214242487.11887.35.camel@koto.keithp.com> <21d7e9970806251823q3405e192q13d4944bd0cc3291@mail.gmail.com> <486308C9.5070709@goop.org> <200807071653.55094.nickpiggin@yahoo.com.au> Organization: Intel X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1575 Lines: 36 On Mon, 7 Jul 2008 16:53:54 +1000 Nick Piggin wrote: > On Thursday 26 June 2008 13:11, Jeremy Fitzhardinge wrote: > > Dave Airlie wrote: > > > > doing tlb flush for iounmap is slow as all hell if you do it a > > > lot, and we can't afford to mmap the whole aperture it can 1GB. > > > > Maybe Nick's vmap reimplementation would help here. It effectively > > allows you to map stuff into the vmalloc space, and do lazy tlb > > flushes to mitigate the cost of map/unmap. He posted the patches > > week or so ago. > > Yeah, it can _really_ help. I'd posted some performance numbers with > the patch which might prompt you to take another look at ioremap. > > 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) -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/