[<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/
Powered by blists - more mailing lists