On 06/05/2019 03:23 AM, Matthew Wilcox wrote:
> On Tue, Jun 04, 2019 at 12:04:06PM +0530, Anshuman Khandual wrote:
>> +++ b/arch/x86/mm/fault.c
>> @@ -46,23 +46,6 @@ kmmio_fault(struct pt_regs *regs, unsigned long addr)
>> return 0;
>> }
>>
>> -s
On 06/04/2019 12:24 PM, Peter Zijlstra wrote:
> On Tue, Jun 04, 2019 at 12:04:06PM +0530, Anshuman Khandual wrote:
>> diff --git a/mm/memory.c b/mm/memory.c
>> index ddf20bd..b6bae8f 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -52,6 +52,7 @@
>>
: Tony Luck
Cc: Fenghua Yu
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Yoshinori Sato
Cc: "David S. Miller"
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Andy Lutomirski
Cc: Dave Hansen
Signed-off-by: Anshuman Khandual
---
Testing:
- Build and boot tested on arm
The task_struct argument is not getting used in __do_page_fault(). Hence
just drop it and use current or cuurent->mm instead where ever required.
This does not change any functionality.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: James Morse
This consolidates page fault information capture and move them bit earlier.
While here it also adds an wrapper is_el0_write_abort(). It also saves some
cycles by replacing multiple user_mode() calls into a single one earlier
during the fault.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
__do_page_fault() is over complicated with multiple goto statements. This
cleans up the code flow and while there drops local variable vm_fault_t.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: James Morse
Cc: Andrey Konovalov
Cc: Christoph Hellwig
rved all existing __do_page_fault() in code comments per Mark
- Dropped 'fixes' from the series's subject line per Will Deacon
V1: https://lkml.org/lkml/2019/5/29/431
Anshuman Khandual (4):
arm64/mm: Drop mmap_sem before calling __do_kernel_fault()
arm64/mm: Drop task_struct argum
die_kernel_fault() gets called without holding mmap_sem. show_pte() can
be made more robust independently but in a later patch.
[1] Conditional block for (is_ttbr0_addr && is_el1_permission_fault)
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: James M
On 05/31/2019 11:18 PM, Matthew Wilcox wrote:
> On Fri, May 31, 2019 at 02:17:43PM +0530, Anshuman Khandual wrote:
>> On 05/30/2019 07:09 PM, Matthew Wilcox wrote:
>>> On Thu, May 30, 2019 at 05:31:15PM +0530, Anshuman Khandual wrote:
>>>> On 05/30/2019
On 05/29/2019 08:23 PM, Mark Rutland wrote:
> On Wed, May 29, 2019 at 06:04:44PM +0530, Anshuman Khandual wrote:
>> This consolidates page fault information capture and move them bit earlier.
>> While here it also adds an wrapper is_write_abort(). It also saves some
>>
On 05/29/2019 08:41 PM, Mark Rutland wrote:
> On Wed, May 29, 2019 at 06:04:45PM +0530, Anshuman Khandual wrote:
>> __do_page_fault() is over complicated with multiple goto statements. This
>> cleans up code flow and while there drops the vm_fault_t argument.
>> Signed-off-
On 05/30/2019 12:04 PM, Christoph Hellwig wrote:
> On Wed, May 29, 2019 at 06:04:45PM +0530, Anshuman Khandual wrote:
>> __do_page_fault() is over complicated with multiple goto statements. This
>> cleans up code flow and while there drops the vm_fault_t argument.
>
>
On 05/30/2019 07:09 PM, Matthew Wilcox wrote:
> On Thu, May 30, 2019 at 05:31:15PM +0530, Anshuman Khandual wrote:
>> On 05/30/2019 04:36 PM, Matthew Wilcox wrote:
>>> The two handle preemption differently. Why is x86 wrong and this one
>>> correct?
>>
>>
On 05/30/2019 04:36 PM, Matthew Wilcox wrote:
> On Thu, May 30, 2019 at 11:25:13AM +0530, Anshuman Khandual wrote:
>> Similar notify_page_fault() definitions are being used by architectures
>> duplicating much of the same code. This attempts to unify them into a
>>
not be wrapped again within CONFIG_KPROBES. Trap number argument can
now contain upto an 'unsigned int' accommodating all possible platforms.
Signed-off-by: Anshuman Khandual
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s
On 05/30/2019 03:36 AM, Andrew Morton wrote:
> On Wed, 29 May 2019 14:46:24 +0530 Anshuman Khandual
> wrote:
>
>> This series enables memory hot remove on arm64 after fixing a memblock
>> removal ordering problem in generic __remove_memory() and one possible
>> arm
On 05/29/2019 06:11 PM, Will Deacon wrote:
> Hi Anshuman,
>
> On Wed, May 29, 2019 at 06:04:41PM +0530, Anshuman Khandual wrote:
>> This series contains some fixes and cleanups for page fault handling in
>> do_page_fault(). This has been boot tested on arm64 platform alon
This consolidates page fault information capture and move them bit earlier.
While here it also adds an wrapper is_write_abort(). It also saves some
cycles by replacing multiple user_mode() calls into a single one earlier
during the fault.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc
The task_struct argument is not getting used in __do_page_fault(). Hence
just drop it and use current or cuurent->mm instead where ever required.
This does not change any functionality.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: James Morse
die_kernel_fault() gets called without holding mmap_sem. show_pte() can
be made more robust independently but in a later patch.
[1] Conditional block for (is_ttbr0_addr && is_el1_permission_fault)
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: James M
__do_page_fault() is over complicated with multiple goto statements. This
cleans up code flow and while there drops the vm_fault_t argument.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: James Morse
Cc: Andrey Konovalov
---
arch/arm64/mm/fault.c
Anshuman Khandual (4):
arm64/mm: Drop mmap_sem before calling __do_kernel_fault()
arm64/mm: Drop task_struct argument from __do_page_fault()
arm64/mm: Consolidate page fault information capture
arm64/mm: Drop vm_fault_t argument from __do_page_fault()
arch/arm64/mm/fault.c | 77
is overall inspired from kernel page table tear down
procedure on X86 architecture.
Signed-off-by: Anshuman Khandual
Acked-by: David Hildenbrand
---
arch/arm64/Kconfig | 3 +
arch/arm64/mm/mmu.c | 211 +++-
2 files changed, 212 insertions(+), 2
viewed-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Signed-off-by: Anshuman Khandual
---
mm/memory_hotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index e096c98..67dfdb8 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hot
will be enabled by a subsequent patch. To avoid racing with
this, take the memory hotplug lock when walking the kernel page table.
Acked-by: David Hildenbrand
Signed-off-by: Anshuman Khandual
---
arch/arm64/mm/ptdump_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/mm
ge table
pages and updated all relevant functions
Changes in V1: (https://lkml.org/lkml/2019/4/3/28)
[1] https://lkml.org/lkml/2019/5/28/584
Anshuman Khandual (3):
mm/hotplug: Reorder arch_remove_memory() call in __remove_memory()
arm64/mm: Hold memory hotplug lock while walking for kernel page table
On 05/21/2019 04:04 PM, Michal Hocko wrote:
> On Tue 21-05-19 08:25:55, Anshuman Khandual wrote:
>> On 05/20/2019 10:29 PM, Tim Murray wrote:
> [...]
>>> not seem to introduce a noticeable hot start penalty, not does it
>>> cause an increase in performan
On 05/28/2019 01:50 PM, Ard Biesheuvel wrote:
> On 5/28/19 10:10 AM, Anshuman Khandual wrote:
>>
>>
>> On 05/23/2019 03:52 PM, Ard Biesheuvel wrote:
>>> Wire up the special helper functions to manipulate aliases of vmalloc
>>> regions in the linear map.
&
On 05/23/2019 03:52 PM, Ard Biesheuvel wrote:
> In order to avoid transient inconsistencies where freed code pages
> are remapped writable while stale TLB entries still exist on other
> cores, mark the kprobes text pages with the VM_FLUSH_RESET_PERMS
> attribute. This instructs the core vmalloc
On 05/23/2019 03:52 PM, Ard Biesheuvel wrote:
> Wire up the special helper functions to manipulate aliases of vmalloc
> regions in the linear map.
IMHO the commit message here could be bit more descriptive because of the
amount of changes this patch brings in.
>
> Signed-off-by: Ard
On 05/23/2019 03:52 PM, Ard Biesheuvel wrote:
> Now that the core code manages the executable permissions of code
> regions of modules explicitly, it is no longer necessary to create
I guess the permission transition for various module sections happen
through module_enable_[ro|nx]() after
On 05/21/2019 03:50 PM, David Hildenbrand wrote:
> On 20.05.19 07:18, Anshuman Khandual wrote:
>> The arch code for hot-remove must tear down portions of the linear map and
>> vmemmap corresponding to memory being removed. In both cases the page
>> tables mapping these
There are no callers for the functions which will pass unaligned physical
addresses. Hence just change these BUG_ON() checks into VM_BUG_ON() which
gets compiled out unless CONFIG_VM_DEBUG is enabled.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc
On 05/27/2019 12:07 PM, Ard Biesheuvel wrote:
> On Mon, 27 May 2019 at 06:02, Anshuman Khandual
> wrote:
>> There are no callers for the functions which will pass unaligned physical
>> addresses. Hence just drop these BUG_ON() checks which are not required.
>>
> This
On 05/24/2019 11:38 PM, Will Deacon wrote:
> On Thu, May 23, 2019 at 04:03:16PM +0100, Robin Murphy wrote:
>> diff --git a/arch/arm64/include/asm/pgtable.h
>> b/arch/arm64/include/asm/pgtable.h
>> index 2c41b04708fe..a6378625d47c 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++
while running 100
> KVM
> guest instances.
>
> This patch fixes the issue by ensuring that the page belongs to a valid PFN
> when we fallback to using the lower limit of the scan range upon failure in
> fast_isolate_freepages().
>
> Fixes: 5a811889de10f1eb ("mm, compaction: use free lists to quickly locate a
> migration target")
> Reported-by: Marc Zyngier
> Signed-off-by: Suzuki K Poulose
Reviewed-by: Anshuman Khandual
There are no callers for the functions which will pass unaligned physical
addresses. Hence just drop these BUG_ON() checks which are not required.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
---
arch/arm64/mm/mmu.c | 2 --
1 file changed, 2 deletions
the
MMU specifications. Create page table level specific wrappers for kernel
huge mapping entries and just drop mk_sect_prot() which does not have any
other user.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
---
arch/arm64/include/asm/pgtable.h | 9
On 05/22/2019 10:12 PM, Mark Rutland wrote:
> On Thu, May 16, 2019 at 01:05:29PM +0200, Michal Hocko wrote:
>> On Thu 16-05-19 11:23:54, Mark Rutland wrote:
>>> Hi Michal,
>>>
>>> On Wed, May 15, 2019 at 06:58:47PM +0200, Michal Hocko wrote:
>>>
On 05/23/2019 02:10 PM, David Hildenbrand wrote:
> On 16.05.19 13:16, Michal Hocko wrote:
>> On Thu 16-05-19 16:36:12, Anshuman Khandual wrote:
>>> On 05/16/2019 03:53 PM, Mark Rutland wrote:
>>>> Hi Michal,
>>>>
>>>> On Wed, May 15, 2019 at 06
On 05/21/2019 03:44 PM, Michal Hocko wrote:
> On Mon 20-05-19 10:48:35, Anshuman Khandual wrote:
>> The arm64 page table dump code can race with concurrent modification of the
>> kernel page tables. When a leaf entries are modified concurrently, the dump
>> code may log
On 05/21/2019 02:50 PM, Tengfei Fan wrote:
> While printing a task's backtrace and this task isn't
> current task, it is possible that task's fp and fp+8
> have the same value, so cannot break the while loop.
> This can break while loop if this task had been
> rescheduled during print this task's
PTE_VALID signifies that the last level page table entry is valid and it is
MMU recognized while walking the page table. This is not a software defined
PTE bit and should not be listed like one. Just move it to appropriate
header file.
Signed-off-by: Anshuman Khandual
Cc: Catalin Marinas
Cc
Replace all open encoded contiguous huge page size computations with
available macro encodings CONT_PTE_SIZE and CONT_PMD_SIZE. There are other
instances where these macros are used in the file and this change makes it
consistently use the same mnemonic.
Signed-off-by: Anshuman Khandual
Cc
On 05/20/2019 10:29 PM, Tim Murray wrote:
> On Sun, May 19, 2019 at 11:37 PM Anshuman Khandual
> wrote:
>>
>> Or Is the objective here is reduce the number of processes which get killed
>> by
>> lmkd by triggering swapping for the unused memory (user hinted) s
rruption"
> Slightly modify the error message to improve clarity.
>
> Signed-off-by: Jane Chu
Reviewed-by: Anshuman Khandual
On 05/21/2019 01:03 AM, Dan Williams wrote:
> On Mon, May 20, 2019 at 12:27 PM Jerome Glisse wrote:
>>
>> On Mon, May 20, 2019 at 11:07:38AM +0530, Anshuman Khandual wrote:
>>> On 05/18/2019 03:20 AM, Andrew Morton wrote:
>>>> On Fri, 17 May 2019 16:08:34
On 05/20/2019 09:22 AM, Minchan Kim wrote:
> - Problem
>
> Naturally, cached apps were dominant consumers of memory on the system.
> However, they were not significant consumers of swap even though they are
> good candidate for swap. Under investigation, swapping out only begins
> once the low
On 05/18/2019 03:20 AM, Andrew Morton wrote:
> On Fri, 17 May 2019 16:08:34 +0530 Anshuman Khandual
> wrote:
>
>> The presence of struct page does not guarantee linear mapping for the pfn
>> physical range. Device private memory which is non-coherent is excluded
>>
will be enabled by a subsequent patch. To avoid racing with
this, take the memory hotplug lock when walking the kernel page table.
Acked-by: David Hildenbrand
Signed-off-by: Anshuman Khandual
---
arch/arm64/mm/ptdump_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/mm
viewed-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Signed-off-by: Anshuman Khandual
---
mm/memory_hotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 328878b..1dbda48 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hot
is in use to avoid this problem.
Fixes: 324420bf91f60582 ("arm64: add support for ioremap() block mappings")
Acked-by: Ard Biesheuvel
Signed-off-by: Mark Rutland
Signed-off-by: Anshuman Khandual
Cc: Ard Biesheuvel
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/mm/mmu.c | 11 --
is overall inspired from kernel page table tear down
procedure on X86 architecture.
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 3 +
arch/arm64/mm/mmu.c | 212 +++-
2 files changed, 213 insertions(+), 2 deletions(-)
diff --git a/arch
(https://lkml.org/lkml/2019/4/3/28)
Anshuman Khandual (3):
mm/hotplug: Reorder arch_remove_memory() call in __remove_memory()
arm64/mm: Hold memory hotplug lock while walking for kernel page table dump
arm64/mm: Enable memory hot remove
Mark Rutland (1):
arm64/mm: Inhibit huge-vmap with ptdump
out virtual address for a given pfn.
Signed-off-by: Anshuman Khandual
---
All these helper functions are all pfn_t related but could not figure out
another way of determining a private pfn without looking into it's struct
page. pfn_t_to_virt() is not getting used any where in mainline kernel.Is
On 05/17/2019 09:38 AM, Jane Chu wrote:
> Some user who install SIGBUS handler that does longjmp out
What the longjmp about ? Are you referring to the mechanism of catching the
signal which was registered ?
> therefore keeping the process alive is confused by the error
> message
>
On 05/16/2019 04:27 PM, Mark Rutland wrote:
> On Thu, May 16, 2019 at 11:04:48AM +0530, Anshuman Khandual wrote:
>> On 05/15/2019 05:19 PM, Mark Rutland wrote:
>>> On Tue, May 14, 2019 at 02:30:07PM +0530, Anshuman Khandual wrote:
>>>> Memory removal from an arc
On 05/16/2019 03:53 PM, Mark Rutland wrote:
> Hi Michal,
>
> On Wed, May 15, 2019 at 06:58:47PM +0200, Michal Hocko wrote:
>> On Tue 14-05-19 14:30:05, Anshuman Khandual wrote:
>>> The arm64 pagetable dump code can race with concurrent modification of the
>>>
On 05/15/2019 05:19 PM, Mark Rutland wrote:
> Hi Anshuman,
>
> On Tue, May 14, 2019 at 02:30:07PM +0530, Anshuman Khandual wrote:
>> Memory removal from an arch perspective involves tearing down two different
>> kernel based mappings i.e vmemmap and linear while releasing
On 05/15/2019 05:21 AM, Roman Gushchin wrote:
> __vunmap() calls find_vm_area() twice without an obvious reason:
> first directly to get the area pointer, second indirectly by calling
> vm_remove_mappings()->remove_vm_area(), which is again searching
> for the area.
>
> To remove this
On 05/15/2019 05:21 AM, Roman Gushchin wrote:
> Vmalloc() is getting more and more used these days (kernel stacks,
> bpf and percpu allocator are new top users), and the total %
> of memory consumed by vmalloc() can be pretty significant
> and changes dynamically.
>
> /proc/meminfo is the best
On 05/15/2019 05:21 AM, Roman Gushchin wrote:
> __vunmap() calls find_vm_area() twice without an obvious reason:
> first directly to get the area pointer, second indirectly by calling
> vm_remove_mappings()->remove_vm_area(), which is again searching
> for the area.
>
> To remove this
On 05/14/2019 09:10 PM, Mark Rutland wrote:
> On Tue, May 14, 2019 at 02:30:05PM +0530, Anshuman Khandual wrote:
>> The arm64 pagetable dump code can race with concurrent modification of the
>> kernel page tables. When a leaf entries are modified concurrently, the dump
>&g
nel linear mapping. Now enable memory hot
remove on arm64 platforms by default with ARCH_ENABLE_MEMORY_HOTREMOVE.
This implementation is overall inspired from kernel page table tear down
procedure on X86 architecture.
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 3 +
arch/arm64/mm/mm
installing a huge mapping in the vmalloc region. To avoid racing with these
cases, take the memory hotplug lock when walking the kernel page table.
Signed-off-by: Anshuman Khandual
---
arch/arm64/mm/ptdump_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/mm/ptdump_debugfs.c b
viewed-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Signed-off-by: Anshuman Khandual
---
mm/memory_hotplug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 0082d69..71d0d79 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hot
is in use to avoid this problem.
Fixes: 324420bf91f60582 ("arm64: add support for ioremap() block mappings")
Signed-off-by: Mark Rutland
Signed-off-by: Anshuman Khandual
Cc: Ard Biesheuvel
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/mm/mmu.c | 11 ---
1 file changed
Robin Murphy
- Skipped calling into pgtable_page_dtor() for linear mapping page table
pages and updated all relevant functions
Changes in V1: (https://lkml.org/lkml/2019/4/3/28)
Anshuman Khandual (3):
mm/hotplug: Reorder arch_remove_memory() call in __remove_memory()
arm64/mm: Hold memory
On 05/13/2019 01:52 PM, David Hildenbrand wrote:
> On 14.04.19 07:59, Anshuman Khandual wrote:
>> This series enables memory hot remove on arm64 after fixing a memblock
>> removal ordering problem in generic __remove_memory(). This is based
>> on the following arm64 wo
On 04/24/2019 02:08 AM, Pavel Tatashin wrote:
> sparsemem section size determines the maximum size and alignment that
> is allowed to offline/online memory block. The bigger the size the less
> the clutter in /sys/devices/system/memory/*. On the other hand, however,
> there is less flexability
On 04/23/2019 09:35 PM, Mark Rutland wrote:
> On Tue, Apr 23, 2019 at 01:01:58PM +0530, Anshuman Khandual wrote:
>> Generic usage for init_mm.pagetable_lock
>>
>> Unless I have missed something else these are the generic init_mm kernel
>> page table
>> modifier
On 04/23/2019 01:21 PM, David Hildenbrand wrote:
> On 23.04.19 09:45, Anshuman Khandual wrote:
>>
>>
>> On 04/23/2019 01:07 PM, David Hildenbrand wrote:
>>> On 23.04.19 09:31, Anshuman Khandual wrote:
>>>>
>>>>
>>>> On 04/18/20
On 04/23/2019 01:07 PM, David Hildenbrand wrote:
> On 23.04.19 09:31, Anshuman Khandual wrote:
>>
>>
>> On 04/18/2019 10:58 AM, Anshuman Khandual wrote:
>>> On 04/17/2019 11:09 PM, Mark Rutland wrote:
>>>> On Wed, Apr 17, 2019 at 10:15:35PM +0530, Anshu
On 04/18/2019 10:58 AM, Anshuman Khandual wrote:
> On 04/17/2019 11:09 PM, Mark Rutland wrote:
>> On Wed, Apr 17, 2019 at 10:15:35PM +0530, Anshuman Khandual wrote:
>>> On 04/17/2019 07:51 PM, Mark Rutland wrote:
>>>> On Wed, Apr 17, 2019 at 03:28:18PM
On 04/17/2019 11:09 PM, Mark Rutland wrote:
> On Wed, Apr 17, 2019 at 10:15:35PM +0530, Anshuman Khandual wrote:
>> On 04/17/2019 07:51 PM, Mark Rutland wrote:
>>> On Wed, Apr 17, 2019 at 03:28:18PM +0530, Anshuman Khandual wrote:
>>>> On 04/15/2019 07:18 PM, Mark Ru
On 04/17/2019 07:51 PM, Mark Rutland wrote:
> On Wed, Apr 17, 2019 at 03:28:18PM +0530, Anshuman Khandual wrote:
>> On 04/15/2019 07:18 PM, Mark Rutland wrote:
>>> On Sun, Apr 14, 2019 at 11:29:13AM +0530, Anshuman Khandual wrote:
>>>> Memory removal from an arc
On 04/15/2019 07:18 PM, Mark Rutland wrote:
> Hi Anshuman,
>
> On Sun, Apr 14, 2019 at 11:29:13AM +0530, Anshuman Khandual wrote:
>> Memory removal from an arch perspective involves tearing down two different
>> kernel based mappings i.e vmemmap and linear while releasing
On 04/15/2019 07:28 PM, David Hildenbrand wrote:
> On 14.04.19 07:59, Anshuman Khandual wrote:
>> Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs
>> entries between memory block and node. It first checks pfn validity with
>> pfn_valid_within(
On 04/15/2019 07:25 PM, David Hildenbrand wrote:
>> +
>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>> +int arch_remove_memory(int nid, u64 start, u64 size, struct vmem_altmap
>> *altmap)
>> +{
>> +unsigned long start_pfn = start >> PAGE_SHIFT;
>> +unsigned long nr_pages = size >> PAGE_SHIFT;
>>
viewed-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Signed-off-by: Anshuman Khandual
---
mm/memory_hotplug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 0082d69..71d0d79 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hot
-by: Anshuman Khandual
---
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/pgtable.h | 2 +
arch/arm64/mm/mmu.c | 221 ++-
3 files changed, 224 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c383625
in arch_add_memory() per Robin Murphy
- Skipped calling into pgtable_page_dtor() for linear mapping page table
pages and updated all relevant functions
Changes in V1: (https://lkml.org/lkml/2019/4/3/28)
Anshuman Khandual (2):
mm/hotplug: Reorder arch_remove_memory() call in __remove_memory()
arm64/mm
On 04/08/2019 09:33 AM, Ira Weiny wrote:
> On Sun, Apr 07, 2019 at 03:11:00PM -0700, Dan Williams wrote:
>> On Thu, Apr 4, 2019 at 2:47 AM Robin Murphy wrote:
>>>
>>> On 04/04/2019 06:04, Dan Williams wrote:
>>>> On Wed, Apr 3, 2019 a
On 04/03/2019 11:38 PM, Dan Williams wrote:
> On Tue, Apr 2, 2019 at 9:30 PM Anshuman Khandual
> wrote:
>>
>> This series enables memory hot remove on arm64, fixes a memblock removal
>> ordering problem in generic __remove_memory(), enables sysfs memory probe
>&g
On 04/04/2019 05:28 PM, Oscar Salvador wrote:
> On Thu, Apr 04, 2019 at 11:09:22AM +0530, Anshuman Khandual wrote:
>>> Do these need to be __meminit? AFAICS it's effectively redundant with the
>>> containing #ifdef, and removal feels like it's inherently a later-than-i
keep it disabled to continue with the existing semantics.
Signed-off-by: Anshuman Khandual
---
arch/arm64/mm/mmu.c | 2 +-
arch/ia64/mm/discontig.c | 2 +-
arch/x86/mm/init_64.c| 4 ++--
include/linux/mm.h | 5 +++--
mm/sparse-vmemmap.c | 14 ++
5 files changed
mappings. Just remove the ARCH_HAS_ZONE_DEVICE dependency from
ARM64_4K_PAGES.
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 2 +-
arch/arm64/mm/mmu.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index
On 04/03/2019 02:47 PM, Michal Hocko wrote:
> On Wed 03-04-19 10:00:04, Anshuman Khandual wrote:
>> Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs
>> entries between memory block and node. It first checks pfn validity with
>> pfn_valid_within(
On 04/03/2019 11:27 PM, Robin Murphy wrote:
> On 03/04/2019 18:32, Logan Gunthorpe wrote:
>>
>>
>> On 2019-04-02 10:30 p.m., Anshuman Khandual wrote:
>>> Memory removal from an arch perspective involves tearing down two different
>>> kernel based mappings
On 04/03/2019 11:02 PM, Logan Gunthorpe wrote:
>
>
> On 2019-04-02 10:30 p.m., Anshuman Khandual wrote:
>> Memory removal from an arch perspective involves tearing down two different
>> kernel based mappings i.e vmemmap and linear while releasing related page
>
On 04/03/2019 06:45 PM, Steven Price wrote:
> On 03/04/2019 13:37, Robin Murphy wrote:
>> [ +Steve ]
>>
>> Hi Anshuman,
Hi Steve,
>>
>> On 03/04/2019 05:30, Anshuman Khandual wrote:
>
>
>
>>> diff --git a/arch/arm64/include/asm/pgtable
On 04/03/2019 06:07 PM, Robin Murphy wrote:
> [ +Steve ]
>
> Hi Anshuman,
>
> On 03/04/2019 05:30, Anshuman Khandual wrote:
>> Memory removal from an arch perspective involves tearing down two different
>> kernel based mappings i.e vmemmap and linear while rele
On 04/03/2019 01:50 PM, David Hildenbrand wrote:
> On 03.04.19 06:30, Anshuman Khandual wrote:
>> Sysfs memory probe interface (/sys/devices/system/memory/probe) can accept
>> starting physical address of an entire memory block to be hot added into
>> the kernel
On 04/03/2019 06:42 PM, Robin Murphy wrote:
> On 03/04/2019 09:20, David Hildenbrand wrote:
>> On 03.04.19 06:30, Anshuman Khandual wrote:
>>> Sysfs memory probe interface (/sys/devices/system/memory/probe) can accept
>>> starting physical address of an entire m
On 04/03/2019 09:37 PM, Jerome Glisse wrote:
> On Wed, Apr 03, 2019 at 02:58:28PM +0100, Robin Murphy wrote:
>> [ +Dan, Jerome ]
>>
>> On 03/04/2019 05:30, Anshuman Khandual wrote:
>>> Arch implementation for functions which create or destroy vmemmap mapping
>&
On 04/03/2019 07:28 PM, Robin Murphy wrote:
> [ +Dan, Jerome ]
>
> On 03/04/2019 05:30, Anshuman Khandual wrote:
>> Arch implementation for functions which create or destroy vmemmap mapping
>> (vmemmap_populate, vmemmap_free) can comprehend and allocate from inside
&
enable ZONE_DEVICE by subscribing to ARCH_HAS_ZONE_DEVICE. But this is only
applicable for ARM64_4K_PAGES (ARM64_SWAPPER_USES_SECTION_MAPS) only which
creates vmemmap section mappings and utilize vmem_altmap structure.
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 1 +
1 file changed, 1
ZE from mm/hmm.c as well.
[anshuman: Consolidated mm/hmm.c instance and updated the commit message]
Signed-off-by: Robin Murphy
Signed-off-by: Anshuman Khandual
---
include/linux/mmzone.h | 1 +
kernel/memremap.c | 10 --
mm/hmm.c | 2 --
3 files changed, 5 insert
istent.
Signed-off-by: Anshuman Khandual
---
mm/memory_hotplug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 0082d69..71d0d79 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1872,11 +1872,10 @@ void __ref __remove_
with struct vmem_altmap which reserves range of device memory to be used
for it's own struct pages.
On arm64 platforms this enables vmemmap_populate() & vmemmap_free() which
creates & destroys struct page mapping to accommodate a given instance of
struct vmem_altmap.
Signed-off-by: Anshuman
801 - 900 of 2971 matches
Mail list logo
