; - vstart = (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN,
> + vstart = (void *)__get_free_pages(gfp_mask | __GFP_NOWARN,
> order);
> if (vstart)
> break;
>
Reviewed-by: Anshuman Khandual
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
like above, but with some error catching.
> */
> -int
> -swiotlb_late_init_with_default_size(size_t default_size)
> +int swiotlb_init_late(size_t size)
> {
> - unsigned long nslabs =
> - ALIGN(default_size >> IO_TLB_SHIFT, IO_TLB_
swiotlb_init_with_tbl(char *tlb, unsigned long
> nslabs, int verbose)
>
> if (verbose)
> swiotlb_print_info();
> - swiotlb_set_max_segment(mem->nslabs << IO_TLB_SHIFT);
> return 0;
> }
>
> @@ -368,7 +355,6 @@ swiotlb_late_init_with_tbl(char
size_t tbl_size, slots_size;
>
> + if (swiotlb_force == SWIOTLB_FORCE)
> + return;
> +
> if (!mem->nslabs)
> return;
>
>
Reviewed-by: Anshuman Khandual
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
eturn swiotlb_map(dev, phys, size, dir, attrs);
>
> if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
> - if (swiotlb_force != SWIOTLB_NO_FORCE)
> + if (is_swiotlb_active(dev))
> return swiotlb_map(dev, phys, size, dir, attrs);
>
On 2/22/22 9:05 PM, Christoph Hellwig wrote:
> The IOMMU table tries to separate the different IOMMUs into different
> backends, but actually requires various cross calls.
>
> Rewrite the code to do the generic swiotlb/swiotlb-xen setup directly
> in pci-dma.c and then just call into the IOMMU d
On 2/22/22 9:05 PM, Christoph Hellwig wrote:
> Allow to pass a remap argument to the swiotlb initialization functions
> to handle the Xen/x86 remap case. ARM/ARM64 never did any remapping
> from xen_swiotlb_fixup, so we don't even need that quirk.
>
> Signed-off-by: Christoph Hellwig
> ---
> ar
On 2/12/21 3:09 PM, David Hildenbrand wrote:
> 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 6
On 2/11/21 1:34 PM, Christoph Hellwig wrote:
> On Thu, Feb 11, 2021 at 11:52:11AM +0530, Anshuman Khandual wrote:
>> Type cast MAX_ORDER as unsigned int to fix the following build warning.
>>
>> In file included from ./include/linux/kernel.h:14,
>>
On 2/11/21 1:31 PM, Christoph Hellwig wrote:
> On Thu, Feb 11, 2021 at 11:52:10AM +0530, 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
>&g
On 2/11/21 1:30 PM, Christoph Hellwig wrote:
>> -if (HPAGE_SHIFT > PAGE_SHIFT)
>> +if ((HPAGE_SHIFT > PAGE_SHIFT) && (HUGETLB_PAGE_ORDER < MAX_ORDER))
>
> No need for the braces.
Will drop them.
___
iommu mailing list
iommu@lists.linux-founda
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:1080
guous.c:402:35: note: in expansion of macro ‘max’
phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: iommu@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Anshuman Khandual
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index f39568b28ec1..8e3a5578f663 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1909,6 +1909,10 @@ config ARCH_ENABLE_THP_MIGRATION
certain platforms like arm64. Lets prevent
the scenario by first checking HUGETLB_PAGE_ORDER against MAX_ORDER, before
its assignment as pageblock_order.
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
mm/page_alloc.c | 2 +-
1 file
rg
Cc: iommu@lists.linux-foundation.org
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Changes in V1:
- Rebased on 5.11-rc7
- Dropped the RFC
Changes in RFC:
https://lore.kernel.org/linux-mm/1612422084-30429-1-git-send-email-anshuman.khand...@arm.com/
Anshuman Khandual (3):
mm/pag
On 2/4/21 12:31 PM, 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:
> CP
On 2/5/21 1:50 PM, David Hildenbrand wrote:
> 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 cert
guous.c:402:35: note: in expansion of macro ‘max’
phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: iommu@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Anshuman Khandual
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 175914f2f340..c4acf8230f20 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1918,6 +1918,10 @@ config ARCH_ENABLE_THP_MIGRATION
certain platforms like arm64. Lets prevent
the scenario by first checking HUGETLB_PAGE_ORDER against MAX_ORDER, before
its assignment as pageblock_order.
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
mm/page_alloc.c | 2 +-
1 file
rg
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Anshuman Khandual (3):
mm/page_alloc: Fix pageblock_order when HUGETLB_PAGE_ORDER >= MAX_ORDER
arm64/hugetlb: Enable HUGETLB_PAGE_SIZE_VARIABLE
dma-contiguous: Type cast MAX_ORDER as unsigned int
arch/arm64/Kconfig | 4 +
[powerpc]
Acked-by: Doug Ledford [drivers/infiniband]
Signed-off-by: Anshuman Khandual
---
arch/alpha/include/asm/topology.h | 3 ++-
arch/ia64/kernel/numa.c | 2 +-
arch/ia64/mm/discontig.c | 6 +++---
arch/powerpc/inclu
t;nid == -1"
2. git grep "node == -1"
3. git grep "nid = -1"
4. git grep "node = -1"
NOTE: I can still split the first patch into multiple ones - one for each
subsystem as suggested by Lubomir if that would be better.
Anshuman Khandual (1):
mm: Replace all open e
From: Stephen Rothwell
This replaces all open encodings in tools with NUMA_NO_NODE.
Also linux/numa.h is now needed for the perf build.
Signed-off-by: Anshuman Khandual
Signed-off-by: Stephen Rothwell
---
tools/include/linux/numa.h | 16
tools/perf/bench/numa.c| 6
On 12/05/2018 02:56 AM, Lubomir Rintel wrote:
> On Mon, 2018-11-26 at 17:56 +0530, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in ther
On 12/05/2018 10:30 AM, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 19717e78a04d51512cf0e7b9b09c61f06b2af071 ("[PATCH V2] mm: Replace all
> open encodings for NUMA_NO_NODE")
> url:
> https://github.com/0day-ci/lin
On 11/26/2018 06:18 PM, David Hildenbrand wrote:
> On 26.11.18 13:26, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace
like
'invalid node' from various places redirecting them to a common definition.
Signed-off-by: Anshuman Khandual
---
Changes in V2:
- Added inclusion of 'numa.h' header at various places per Andrew
- Updated 'dev_to_node' to use NUMA_NO_NODE instead per Vinod
Changes
On 11/24/2018 07:35 PM, Vinod Koul wrote:
> On 23-11-18, 15:24, Anshuman Khandual wrote:
>
>> --- a/drivers/dma/dmaengine.c
>> +++ b/drivers/dma/dmaengine.c
>> @@ -386,7 +386,8 @@ EXPORT_SYMBOL(dma_issue_pending_all);
>> static bool dma_chan_is_local(
On 11/24/2018 05:14 AM, Andrew Morton wrote:
> On Fri, 23 Nov 2018 15:24:16 +0530 Anshuman Khandual
> wrote:
>
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
min
On 11/23/2018 04:06 PM, David Hildenbrand wrote:
> On 23.11.18 10:54, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace
like
'invalid node' from various places redirecting them to a common definition.
Signed-off-by: Anshuman Khandual
---
Changes in V1:
- Dropped OCFS2 changes per Joseph
- Dropped media/video drivers changes per Hans
RFC - https://patchwork.kernel.org/patch/10678035/
Build tested this wit
On 11/12/2018 02:13 PM, Hans Verkuil wrote:
> On 11/12/2018 03:41 AM, Anshuman Khandual wrote:
>> At present there are multiple places where invalid node number is encoded
>> as -1. Even though implicitly understood it is always better to have macros
>> in there. Replace
On 11/12/2018 09:40 AM, Anshuman Khandual wrote:
>
>
> On 11/12/2018 09:27 AM, Joseph Qi wrote:
>> For ocfs2 part, node means host in the cluster, not NUMA node.
>>
>
> Does not -1 indicate an invalid node which can never be present ?
>
My bad, got it wrong.
On 11/12/2018 09:27 AM, Joseph Qi wrote:
> For ocfs2 part, node means host in the cluster, not NUMA node.
>
Does not -1 indicate an invalid node which can never be present ?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxf
like
'invalid node' from various places redirecting them to a common definition.
Signed-off-by: Anshuman Khandual
---
Build tested this with multiple cross compiler options like alpha, sparc,
arm64, x86, powerpc64le etc with their default config which might not have
compiled tested all driv
On 04/15/2018 08:29 PM, Christoph Hellwig wrote:
> This way we have one central definition of it, and user can select it as
> needed. Note that we also add a second ARCH_HAS_SWIOTLB symbol to
> indicate the architecture supports swiotlb at all, so that we can still
> make the usage optional for a
On 04/16/2018 07:28 PM, David Miller wrote:
> From: Anshuman Khandual
> Date: Mon, 16 Apr 2018 14:26:07 +0530
>
>> On 04/15/2018 08:29 PM, Christoph Hellwig wrote:
>>> This code is only used by sparc, and all new iommu drivers should use the
>>> drivers/iommu/ f
; Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 04/15/2018 08:29 PM, Christoph Hellwig wrote:
> This way we have one central definition of it, and user can select it as
> needed.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
___
iommu mailing list
iommu
On 04/15/2018 08:29 PM, Christoph Hellwig wrote:
> This function is only used by built-in code.
>
> Reviewed-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
___
iommu mailing list
iommu@lists.linux-foundation.
On 04/15/2018 08:29 PM, Christoph Hellwig wrote:
> This way we have one central definition of it, and user can select it as
> needed.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Anshuman Khandual
___
iommu mailing list
iommu
u_tbl_range_free(tbl, bus_addr, npages,
IOMMU_ERROR_CODE);
arch/sparc/kernel/pci_sun4v.c: iommu_tbl_range_free(tbl,
vaddr, npages,
arch/sparc/kernel/pci_sun4v.c: iommu_tbl_range_free(tbl, dma_handle,
npages,
Reviewed-by: Anshuman Khandual
44 matches
Mail list logo
