On Wed, Jul 21, 2010 at 11:19:58AM +0530, Shilimkar, Santosh wrote: > > -----Original Message----- > > From: linux-arm-kernel-boun...@lists.infradead.org [mailto:linux-arm- > > kernel-boun...@lists.infradead.org] On Behalf Of Russell King - ARM Linux > > Sent: Wednesday, July 21, 2010 4:00 AM > > To: step...@codeaurora.org > > Cc: linux-a...@vger.kernel.org; dwal...@codeaurora.org; m...@csn.ul.ie; > > linux-arm-...@vger.kernel.org; linux-ker...@vger.kernel.org; FUJITA > > Tomonori; linux...@kvack.org; a...@firstfloor.org; Zach Pfeffer; Michael > > Bohan; Tim HRM; linux-omap@vger.kernel.org; linux-arm- > > ker...@lists.infradead.org; ebied...@xmission.com > > Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device > > memory management
************************************************************************* > > This is difficult to achieve without remapping kernel memory using L2 > > page tables, so we can unmap pages on 4K page granularity. That's > > going to increase TLB overhead and result in lower system performance > > as there'll be a greater number of MMU misses. ************************************************************************* > > However, one obvious case would be to use highmem-only pages for > > remapping - but you then have to ensure that those pages are never > > kmapped in any way, because those mappings will fall into the same > > unpredictable category that we're already trying to avoid. This > > may be possible, but you'll have to ensure that most of the system > > RAM is in highmem - which poses other problems (eg, if lowmem gets > > low.) > > Why can't we consider an option of removing the old mappings when > we need to create new ones with different attributes as suggested > by Catalin on similar thread previously. This will avoid the duplicate > mapping with different attributes issue on newer ARMs. See the first paragraph which I've highlighted above. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
