linux-kernel - Re: [Linaro-mm-sig] [PATCH 6/8] drivers: add Contiguous Memory Allocator

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]

Date:	Thu, 7 Jul 2011 01:29:05 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>
cc:	linaro-mm-sig@...ts.linaro.org,
	'Daniel Walker' <dwalker@...eaurora.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	linux-media@...r.kernel.org, 'Jonathan Corbet' <corbet@....net>,
	'Mel Gorman' <mel@....ul.ie>,
	'Chunsang Jeong' <chunsang.jeong@...aro.org>,
	lkml <linux-kernel@...r.kernel.org>,
	'Michal Nazarewicz' <mina86@...a86.com>,
	'Jesse Barker' <jesse.barker@...aro.org>,
	'Kyungmin Park' <kyungmin.park@...sung.com>,
	'KAMEZAWA Hiroyuki' <kamezawa.hiroyu@...fujitsu.com>,
	'Andrew Morton' <akpm@...ux-foundation.org>,
	linux-mm@...ck.org, linux-arm-kernel@...ts.infradead.org,
	'Ankita Garg' <ankita@...ibm.com>
Subject: Re: [Linaro-mm-sig] [PATCH 6/8] drivers: add Contiguous Memory
 Allocator

On Wed, 6 Jul 2011, Arnd Bergmann wrote:

> On Wednesday 06 July 2011 21:10:07 Nicolas Pitre wrote:
> > If you get a highmem page, because the cache is VIPT, that page might 
> > still be cached even if it wasn't mapped.  With a VIVT cache we must 
> > flush the cache whenever a highmem page is unmapped.  There is no such 
> > restriction with VIPT i.e. ARMv6 and above.  Therefore to make sure the 
> > highmem page you get doesn't have cache lines associated to it, you must 
> > first map it cacheable, then perform cache invalidation on it, and 
> > eventually remap it as non-cacheable.  This is necessary because there 
> > is no way to perform cache maintenance on L1 cache using physical 
> > addresses unfortunately.  See commit 7e5a69e83b for an example of what 
> > this entails (fortunately commit 3e4d3af501 made things much easier and 
> > therefore commit 39af22a79 greatly simplified things).
> 
> Ok, thanks for the explanation. This definitely makes the highmem approach
> much harder to get right, and slower. Let's hope then that Marek's approach
> of using small pages for the contiguous memory region and changing their
> attributes on the fly works out better than this.

I would say that both approaches have fairly equivalent complexity.


Nicolas
--
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/