mm: iommu: An API to unify IOMMU, CPU and device memory management
in [Kernel]
|
Prev: Provide special async page fault handler when async PF capability is detected
Next: [PATCH] struct io panic on raid1 - Re: block: unify flags for struct bio and struct request will kernel panic
From: Russell King - ARM Linux on 21 Jul 2010 03:30 On Wed, Jul 21, 2010 at 11:19:58AM +0530, Shilimkar, Santosh wrote: > > -----Original Message----- > > From: linux-arm-kernel-bounces(a)lists.infradead.org [mailto:linux-arm- > > kernel-bounces(a)lists.infradead.org] On Behalf Of Russell King - ARM Linux > > Sent: Wednesday, July 21, 2010 4:00 AM > > To: stepanm(a)codeaurora.org > > Cc: linux-arch(a)vger.kernel.org; dwalker(a)codeaurora.org; mel(a)csn.ul.ie; > > linux-arm-msm(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; FUJITA > > Tomonori; linux-mm(a)kvack.org; andi(a)firstfloor.org; Zach Pfeffer; Michael > > Bohan; Tim HRM; linux-omap(a)vger.kernel.org; linux-arm- > > kernel(a)lists.infradead.org; ebiederm(a)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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Shilimkar, Santosh on 21 Jul 2010 03:50 > -----Original Message----- > From: Russell King - ARM Linux [mailto:linux(a)arm.linux.org.uk] > Sent: Wednesday, July 21, 2010 12:59 PM > To: Shilimkar, Santosh > Cc: stepanm(a)codeaurora.org; linux-arch(a)vger.kernel.org; > dwalker(a)codeaurora.org; mel(a)csn.ul.ie; linux-arm-msm(a)vger.kernel.org; > linux-kernel(a)vger.kernel.org; FUJITA Tomonori; linux-mm(a)kvack.org; > andi(a)firstfloor.org; Zach Pfeffer; Michael Bohan; Tim HRM; linux- > omap(a)vger.kernel.org; linux-arm-kernel(a)lists.infradead.org; > ebiederm(a)xmission.com > Subject: Re: [RFC 1/3 v3] mm: iommu: An API to unify IOMMU, CPU and device > memory management > > On Wed, Jul 21, 2010 at 11:19:58AM +0530, Shilimkar, Santosh wrote: > > > -----Original Message----- > > > From: linux-arm-kernel-bounces(a)lists.infradead.org [mailto:linux-arm- > > > kernel-bounces(a)lists.infradead.org] On Behalf Of Russell King - ARM > Linux > > > Sent: Wednesday, July 21, 2010 4:00 AM > > > To: stepanm(a)codeaurora.org > > > Cc: linux-arch(a)vger.kernel.org; dwalker(a)codeaurora.org; mel(a)csn.ul.ie; > > > linux-arm-msm(a)vger.kernel.org; linux-kernel(a)vger.kernel.org; FUJITA > > > Tomonori; linux-mm(a)kvack.org; andi(a)firstfloor.org; Zach Pfeffer; > Michael > > > Bohan; Tim HRM; linux-omap(a)vger.kernel.org; linux-arm- > > > kernel(a)lists.infradead.org; ebiederm(a)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. > Sorry about missing that para Russell. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 22 Jul 2010 03:40 On Wed, Jul 21, 2010 at 09:25:28PM -0700, Zach Pfeffer wrote: > Yes it is a problem, as Russell has brought up, but there's something > I probably haven't communicated well. I'll use the following example: > > There are 3 devices: A CPU, a decoder and a video output device. All 3 > devices need to map the same 12 MB buffer at the same time. Why do you need the same buffer mapped by the CPU? Let's take your example of a video decoder and video output device. Surely the CPU doesn't want to be writing to the same memory region used for the output picture as the decoder is writing to. So what's the point of mapping that memory into the CPU's address space? Surely the video output device doesn't need to see the input data to the decoder either? Surely, all you need is: 1. a mapping for the CPU for a chunk of memory to pass data to the decoder. 2. a mapping for the decoder to see the chunk of memory to receive data from the CPU. 3. a mapping for the decoder to see a chunk of memory used for the output video buffer. 4. a mapping for the output device to see the video buffer. So I don't see why everything needs to be mapped by everything else. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 22 Jul 2010 03:50
On Wed, Jul 21, 2010 at 09:30:34PM -0700, Zach Pfeffer wrote: > This goes to the nub of the issue. We need a lot of 1 MB physically > contiguous chunks. The system is going to fragment and we'll never get > our 12 1 MB chunks that we'll need, since the DMA API allocator uses > the system pool it will never succeed. By the "DMA API allocator" I assume you mean the coherent DMA interface, The DMA coherent API and DMA streaming APIs are two separate sub-interfaces of the DMA API and are not dependent on each other. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |