Re: [RFC 7/7] iommu/core: split mapping to page sizes as supported by the hardware

2011-09-08 Thread KyongHo Cho
Hi Ohad, On Wed, Sep 7, 2011 at 6:16 PM, Ohad Ben-Cohen o...@wizery.com wrote: Hmm this sounds a bit like a red herring to me; optimization of the :) I agree. sorry. map function is not the main subject here. Especially not when we're discussing mapping of large physically contiguous memory

Re: [RFC 7/7] iommu/core: split mapping to page sizes as supported by the hardware

2011-09-08 Thread Ohad Ben-Cohen
Hi KyongHo, On Thu, Sep 8, 2011 at 3:51 PM, KyongHo Cho pullip@samsung.com wrote: 16MB page is less practical in Linux because Linux kernel is unable to allocated larger physically contiguous memory than 4MB by default. But I also think that it is needed to support 16MB mapping for IO

Re: [RFC 7/7] iommu/core: split mapping to page sizes as supported by the hardware

2011-09-07 Thread Ohad Ben-Cohen
Hi Cho, On Wed, Sep 7, 2011 at 4:30 AM, KyongHo Cho pullip@samsung.com wrote: Please find the following link that I submitted for our IOMMU. https://lkml.org/lkml/2011/7/3/152 s5p_iommu_map/unmap accepts any order of physical address and iova without support of your suggestion if the

Re: [RFC 7/7] iommu/core: split mapping to page sizes as supported by the hardware

2011-09-06 Thread KyongHo Cho
Hi On Sat, Sep 3, 2011 at 2:32 AM, Ohad Ben-Cohen o...@wizery.com wrote: When mapping a memory region, split it to page sizes as supported by the iommu hardware. Always prefer bigger pages, when possible, in order to reduce the TLB pressure. True. It is important for the peripheral devices

[RFC 7/7] iommu/core: split mapping to page sizes as supported by the hardware

2011-09-02 Thread Ohad Ben-Cohen
When mapping a memory region, split it to page sizes as supported by the iommu hardware. Always prefer bigger pages, when possible, in order to reduce the TLB pressure. Conversely, when unmapping a memory region, iterate through its pages, until the region is completely unmapped. The logic to do