linux-kernel - Re: io resources and cached mappings (was: [git pull] drm patches for 2.6.27-rc1)

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: <1224517744.5195.1.camel@koto.keithp.com>
Date:	Mon, 20 Oct 2008 08:49:04 -0700
From:	Keith Packard <keithp@...thp.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	keithp@...thp.com, Jesse Barnes <jbarnes@...tuousgeek.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Dave Airlie <airlied@...ux.ie>,
	Yinghai Lu <yinghai@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.sf.net, Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: io resources and cached mappings (was: [git pull] drm patches
	for 2.6.27-rc1)

On Mon, 2008-10-20 at 13:58 +0200, Ingo Molnar wrote:

> yes but note that by caching the whole mapping on 64-bit we get 
> everything we want: trivially lockless, works from any CPU, can be 
> preempted at will, and there are no ugly INVLPG flushes anywhere.

I was assuming that on 64-bit, the map would be created at driver init
time and be left in place until the driver closed; if that's what you
mean by 'caching', then yes, we should cache the map.

> 32-bit we should handle as well but not design for it.

As long as we get kmap_atomic-like performance, and we get to simplify
our code, I'm up for it.

-- 
keith.packard@...el.com

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