Re: [PATCH] mm: Replace all open encodings for NUMA_NO_NODE

2018-11-23 Thread David Hildenbrand
also have replaced some false positives. > I will appreciate suggestions, inputs and review. > > 1. git grep "nid == -1" > 2. git grep "node == -1" > 3. git grep "nid = -1" > 4. git grep "node = -1" Hopefully you found most users :) D

Re: [PATCH V2] mm: Replace all open encodings for NUMA_NO_NODE

2018-11-26 Thread David Hildenbrand
> - Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod Reviewed-by: David Hildenbrand -- Thanks, David / dhildenb ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/mediatek: Use totalram_pages to setup enable_4GB

2020-06-04 Thread David Hildenbrand
On 04.06.20 17:06, Christoph Hellwig wrote: > On Thu, Jun 04, 2020 at 01:32:40PM +0200, David Hildenbrand wrote: >> Just a thought: If memory hotplug is applicable as well, you might >> either want to always assume data->enable_4GB, or handle memory hotplug >> events from t

Re: [PATCH] iommu/mediatek: Use totalram_pages to setup enable_4GB

2020-06-05 Thread David Hildenbrand
On 04.06.20 17:27, David Hildenbrand wrote: > On 04.06.20 17:06, Christoph Hellwig wrote: >> On Thu, Jun 04, 2020 at 01:32:40PM +0200, David Hildenbrand wrote: >>> Just a thought: If memory hotplug is applicable as well, you might >>> either want to always assume data-&g

Re: [PATCH] iommu/mediatek: Use totalram_pages to setup enable_4GB

2020-06-04 Thread David Hildenbrand
On 04.06.20 11:49, Miles Chen wrote: > On Thu, 2020-06-04 at 10:25 +0200, David Hildenbrand wrote: >> On 04.06.20 10:01, Miles Chen wrote: >>> To build this driver as a kernel module, we cannot use >>> the unexported symbol "max_pfn" to setup enable_4GB.

Re: [PATCH] iommu/mediatek: Use totalram_pages to setup enable_4GB

2020-06-04 Thread David Hildenbrand
On 04.06.20 10:01, Miles Chen wrote: > To build this driver as a kernel module, we cannot use > the unexported symbol "max_pfn" to setup enable_4GB. > > Use totalram_pages() instead to setup enable_4GB. > > Suggested-by: Mike Rapoport > Signed-off-by: Miles Chen

Re: [PATCH v2] iommu/mediatek: check 4GB mode by reading infracfg

2020-07-21 Thread David Hildenbrand
GB only when has_4gb_mode Nit: We tend to place such information below the "---" (adding a second one) such that this information is discarded when the patch is picked up. > > [1] https://lkml.org/lkml/2020/6/3/733 > [2] https://lkml.org/lkml/2020/6/4/136 > [3] https://lkm

Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin

2021-02-08 Thread David Hildenbrand
On 07.02.21 09:18, Zhou Wang wrote: SVA(share virtual address) offers a way for device to share process virtual address space safely, which makes more convenient for user space device driver coding. However, IO page faults may happen when doing DMA operations. As the latency of IO page fault is

Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin

2021-02-08 Thread David Hildenbrand
On 08.02.21 11:13, Song Bao Hua (Barry Song) wrote: -Original Message- From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf Of David Hildenbrand Sent: Monday, February 8, 2021 9:22 PM To: Song Bao Hua (Barry Song) ; Matthew Wilcox Cc: Wangzhou (B) ; linux-ker

Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin

2021-02-08 Thread David Hildenbrand
On 08.02.21 03:27, Song Bao Hua (Barry Song) wrote: -Original Message- From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf Of Matthew Wilcox Sent: Monday, February 8, 2021 2:31 PM To: Song Bao Hua (Barry Song) Cc: Wangzhou (B) ; linux-ker...@vger.kernel.org;

Re: [RFC 2/3] arm64/hugetlb: Enable HUGETLB_PAGE_SIZE_VARIABLE

2021-02-05 Thread David Hildenbrand
On 04.02.21 08:01, Anshuman Khandual wrote: MAX_ORDER which invariably depends on FORCE_MAX_ZONEORDER can be a variable for a given page size, depending on whether TRANSPARENT_HUGEPAGE is enabled or not. In certain page size and THP combinations HUGETLB_PAGE_ORDER can be greater than MAX_ORDER,

Re: [PATCH 0/3] mm/page_alloc: Fix pageblock_order with HUGETLB_PAGE_SIZE_VARIABLE

2021-02-11 Thread David Hildenbrand
On 11.02.21 07:22, Anshuman Khandual wrote: The following warning gets triggered while trying to boot a 64K page size without THP config kernel on arm64 platform. WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080 __fragmentation_index+0xa4/0xc0 Modules linked in: CPU: 5 PID: 124 Comm: kswapd0 Not

Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin

2021-02-11 Thread David Hildenbrand
Again in proper SVA it should be quite unlikely to take a fault caused by something like migration, on the same likelyhood as the CPU. If things are faulting so much this is a problem then I think it is a system level problem with doing too much page motion. My point is that single one SVA

[PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft dependencies on DMA_CMA

2021-04-09 Thread David Hildenbrand
m-ker...@lists.infradead.org Cc: etna...@lists.freedesktop.org Cc: linux-m...@vger.kernel.org Cc: linux-fb...@vger.kernel.org Cc: iommu@lists.linux-foundation.org Signed-off-by: David Hildenbrand --- Let's see if this approach is better for soft dependencies (and if we actually have some hard dep

Re: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft dependencies on DMA_CMA

2021-04-09 Thread David Hildenbrand
On 09.04.21 15:35, Arnd Bergmann wrote: On Fri, Apr 9, 2021 at 1:21 PM David Hildenbrand wrote: Random drivers should not override a user configuration of core knobs (e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA, which depends on CMA, if possible; however

Re: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft dependencies on DMA_CMA

2021-04-12 Thread David Hildenbrand
On 12.04.21 15:12, Robin Murphy wrote: On 2021-04-09 14:39, David Hildenbrand wrote: On 09.04.21 15:35, Arnd Bergmann wrote: On Fri, Apr 9, 2021 at 1:21 PM David Hildenbrand wrote: Random drivers should not override a user configuration of core knobs (e.g., CONFIG_DMA_CMA=n). Applicable

Re: [PATCH 0/3] mm/page_alloc: Fix pageblock_order with HUGETLB_PAGE_SIZE_VARIABLE

2021-02-16 Thread David Hildenbrand
But again, if there are valid use cases then sure, let's make the code fully compatible with HUGETLB_PAGE_ORDER > MAX_ORDER. Given that gigantic HugeTLB allocation can fallback on alloc_contig_pages() or CMA if/when available, is there a real need for HUGETLB_PAGE_ORDER to be upto MAX_ORDER,

Re: [PATCH 0/3] mm/page_alloc: Fix pageblock_order with HUGETLB_PAGE_SIZE_VARIABLE

2021-02-12 Thread David Hildenbrand
On 12.02.21 08:02, Anshuman Khandual wrote: On 2/11/21 2:07 PM, David Hildenbrand wrote: On 11.02.21 07:22, Anshuman Khandual wrote: The following warning gets triggered while trying to boot a 64K page size without THP config kernel on arm64 platform. WARNING: CPU: 5 PID: 124 at mm/vmstat.c

Re: An cma optimization patch is used for cma_[alloc|free].

2021-08-13 Thread David Hildenbrand
On 13.08.21 09:00, Jichao Zou wrote: Pre-allocate CMA memory that configured in device tree, this greatly improves the CMA memory allocation efficiency, cma_[alloc|free] is less than 1ms, old way is took a few ms to tens or hundreds ms. Please send patches as proper emails (man