be using CMA or boottime allocations instead.
So let's make sure that pageblock_order < MAX_ORDER and simplify.
[1] https://lkml.kernel.org/r/87r189a2ks@linux.ibm.com
Signed-off-by: David Hildenbrand
---
drivers/virtio/virtio_mem.c | 9 +++--
include/linux/cma.h | 3 +--
Let's factor out determining the minimum alignment requirement for CMA
and add a helpful comment.
No functional change intended.
Signed-off-by: David Hildenbrand
---
arch/powerpc/include/asm/fadump-internal.h | 5 -
arch/powerpc/kernel/fadump.c | 2 +-
drivers
ski
Cc: Robin Murphy
Cc: Minchan Kim
Cc: Vlastimil Babka
Cc: linuxppc-...@lists.ozlabs.org
Cc: devicet...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: iommu@lists.linux-foundation.org
Cc: linux...@kvack.org
David Hildenbrand (2):
cma: factor out minimum alignment requirement
mm
On 02.02.22 13:18, Oscar Salvador wrote:
> On Wed, Jan 19, 2022 at 02:06:19PM -0500, Zi Yan wrote:
>> From: Zi Yan
>>
>> Enable set_migratetype_isolate() to check specified sub-range for
>> unmovable pages during isolation. Page isolation is done
>> at max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages)
On 05.01.22 22:47, Zi Yan wrote:
> From: Zi Yan
>
> alloc_contig_range() now only needs to be aligned to pageblock_order,
> drop virtio_mem size requirement that it needs to be the max of
> pageblock_order and MAX_ORDER.
>
> Signed-off-by: Zi Yan
> ---
> drivers/virtio/virtio_mem.c | 3 +--
>
On 05.01.22 22:47, Zi Yan wrote:
> From: Zi Yan
>
> Enable set_migratetype_isolate() to check specified sub-range for
> unmovable pages during isolation. Page isolation is done
> at max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) granularity, but not all
> pages within that granularity are intended
On 13.01.22 16:46, Zi Yan wrote:
> On 12 Jan 2022, at 6:04, David Hildenbrand wrote:
>
>> On 05.01.22 22:47, Zi Yan wrote:
>>> From: Zi Yan
>>>
>>> alloc_migration_target() is used by alloc_contig_range() and non-LRU
>>> movable compound pages
On 13.01.22 12:36, Mike Rapoport wrote:
> On Wed, Jan 12, 2022 at 11:54:49AM +0100, David Hildenbrand wrote:
>> On 05.01.22 22:47, Zi Yan wrote:
>>> From: Zi Yan
>>>
>>> This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
>
On 05.01.22 22:47, Zi Yan wrote:
> From: Zi Yan
>
> alloc_migration_target() is used by alloc_contig_range() and non-LRU
> movable compound pages can be migrated. Current code does not allocate the
> right page size for such pages. Check THP precisely using
> is_transparent_huge() and add
On 05.01.22 22:47, Zi Yan wrote:
> From: Zi Yan
>
> In isolate_migratepages_block(), a !PageLRU tail page can be encountered
> when the page is larger than a pageblock. Use compound head page for the
> checks inside and skip the entire compound page when isolation succeeds.
>
This will
On 05.01.22 22:47, Zi Yan wrote:
> From: Zi Yan
>
> This is done in addition to MIGRATE_ISOLATE pageblock merge avoidance.
> It prepares for the upcoming removal of the MAX_ORDER-1 alignment
> requirement for CMA and alloc_contig_range().
>
> MIGRARTE_HIGHATOMIC should not merge with other
On 10.12.21 00:04, Zi Yan wrote:
> From: Zi Yan
>
> Hi all,
Hi,
thanks for working on that!
>
> This patchset tries to remove the MAX_ORDER - 1 alignment requirement for CMA
> and alloc_contig_range(). It prepares for my upcoming changes to make
> MAX_ORDER
> adjustable at boot time[1].
>
On 17.11.21 04:04, Zi Yan wrote:
> On 16 Nov 2021, at 3:58, David Hildenbrand wrote:
>
>> On 15.11.21 20:37, Zi Yan wrote:
>>> From: Zi Yan
>>>
>>> Hi David,
>>
>> Hi,
>>
>> thanks for looking into this.
>>
Hi,
sorry for t
On 15.11.21 20:37, Zi Yan wrote:
> From: Zi Yan
>
> Hi David,
Hi,
thanks for looking into this.
>
> You suggested to make alloc_contig_range() deal with pageblock_order instead
> of
> MAX_ORDER - 1 and get rid of MAX_ORDER - 1 dependency in virtio_mem[1]. This
> patchset is my attempt to
On 13.10.21 14:17, Michael S. Tsirkin wrote:
> On Wed, Oct 13, 2021 at 01:03:46PM +0200, David Hildenbrand wrote:
>> On 13.10.21 12:55, Michael S. Tsirkin wrote:
>>> This will enable cleanups down the road.
>>> The idea is to disable cbs, then add "flush_queued_
On 13.10.21 12:55, Michael S. Tsirkin wrote:
This will enable cleanups down the road.
The idea is to disable cbs, then add "flush_queued_cbs" callback
as a parameter, this way drivers can flush any work
queued after callbacks have been disabled.
Signed-off-by: Michael S. Tsirkin
---
() is the only method in DMA mapping APIs that has this
check, simply drop the pfn_valid() test from dma_map_resource().
Link: https://lore.kernel.org/all/20210824173741.gc...@arm.com/
Signed-off-by: Mike Rapoport
---
Acked-by: David Hildenbrand
--
Thanks,
David / dhildenb
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
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
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
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
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,
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
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
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
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
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;
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
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,
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
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
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
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.
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
> - 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
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
36 matches
Mail list logo
