On 10/16/2017 02:49 PM, changbin...@intel.com wrote:
> From: Changbin Du
>
> The current name free_{huge,transhuge}_page are paired with
> alloc_{huge,transhuge}_page functions, but the actual page free
> function is still free_page() which will indirectly call
> free_{huge,transhuge}_page. So th
On 10/17/2017 01:48 PM, Huang, Ying wrote:
> From: Huang Ying
>
> Now, when the page table is walked in the implementation of
> /proc//pagemap, pmd_soft_dirty() is used for both the PMD huge
> page map and the PMD migration entries. That is wrong,
> pmd_swp_soft_dirty() should be used for the PM
On 10/31/2017 06:15 PM, Vlastimil Babka wrote:
> On 10/19/2017 05:33 PM, Michal Hocko wrote:
>> On Thu 19-10-17 20:26:57, Anshuman Khandual wrote:
>>> Its already assumed that the PageActive flag is clear on the input
>>> page, hence page_lru(page) will pick the base L
On 10/23/2017 08:52 AM, Anshuman Khandual wrote:
> On 10/19/2017 09:03 PM, Michal Hocko wrote:
>> On Thu 19-10-17 20:26:57, Anshuman Khandual wrote:
>>> Its already assumed that the PageActive flag is clear on the input
>>> page, hence page_lru(page) will pick the base L
ke Kravetz
Signed-off-by: Anshuman Khandual
---
Changes in V3:
- Fail any attempts to mirror an existing anon private mapping
- Updated run_vmtests to include these new mremap tests
- Updated the commit message
Changes in V2: (https://patchwork.kernel.org/patch/9861259/)
- Added a test for pr
On 10/19/2017 04:47 AM, Shakeel Butt wrote:
> Recently we have observed high latency in mlock() in our generic
> library and noticed that users have started using tmpfs files even
> without swap and the latency was due to expensive remote LRU cache
> draining.
With and without this I patch I dont
element, the name should reflect it.
Signed-off-by: Anshuman Khandual
---
mm/swap.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/mm/swap.c b/mm/swap.c
index a77d68f..fcd82bc 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -185,7 +185,7 @@ int get_kernel_page
page flags instead of being hard
coded.
Signed-off-by: Anshuman Khandual
---
mm/swap.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/mm/swap.c b/mm/swap.c
index fcd82bc..494276b 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -275,12 +275,10 @@ static void __activate_page
ke Kravetz
Signed-off-by: Anshuman Khandual
Reviewed-by: Mike Kravetz
---
Changes in V4:
- Folded these two test files into just one as per Mike
- Did some renaming of functions, cleans ups etc
Changes in V3: (https://patchwork.kernel.org/patch/10013469/)
- Fail any attempts to mirror an exi
On 10/01/2015 04:18 PM, Pintu Kumar wrote:
> This patch maintains number of oom calls and number of oom kill
> count in /proc/vmstat.
> It is helpful during sluggish, aging or long duration tests.
> Currently if the OOM happens, it can be only seen in kernel ring buffer.
> But during long duration
On 07/27/2018 03:28 PM, Will Deacon wrote:
> Hi Anshuman,
>
> On Fri, Jul 20, 2018 at 09:29:37AM +0530, Anshuman Khandual wrote:
>> This patch series is the follow up on the discussions we had before about
>> the RFC titled [RFC,V2] virtio: Add platform specific DMA API tran
On 07/23/2018 02:38 PM, Michael S. Tsirkin wrote:
> On Mon, Jul 23, 2018 at 11:58:23AM +0530, Anshuman Khandual wrote:
>> On 07/20/2018 06:46 PM, Michael S. Tsirkin wrote:
>>> On Fri, Jul 20, 2018 at 09:29:37AM +0530, Anshuman Khandual wrote:
>>>> This patch
On 07/23/2018 07:46 AM, Anshuman Khandual wrote:
> On 07/20/2018 06:45 PM, Michael S. Tsirkin wrote:
>> On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote:
>>> Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for
>>> virito de
On 01/17/2018 01:37 PM, Michal Hocko wrote:
> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
> [...]
>>> Did you manage to catch _who_ is requesting that anonymous mapping? Do
>>> you need a help with the debugging
On 01/23/2018 06:15 PM, Michal Hocko wrote:
> On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
>> On 01/17/2018 01:37 PM, Michal Hocko wrote:
>>> On Thu 11-01-18 15:38:37, Anshuman Khandual wrote:
>>>> On 01/09/2018 09:43 PM, Michal Hocko wrote:
>>> [...]
On 01/23/2018 09:36 PM, Michal Hocko wrote:
> On Tue 23-01-18 21:28:28, Anshuman Khandual wrote:
>> On 01/23/2018 06:15 PM, Michal Hocko wrote:
>>> On Tue 23-01-18 16:55:18, Anshuman Khandual wrote:
>>>> On 01/17/2018 01:37 PM, Michal Hocko wrote:
>>>>>
On 05/12/2017 01:40 PM, Naoya Horiguchi wrote:
> On Thu, Apr 20, 2017 at 04:36:27PM +0530, Anshuman Khandual wrote:
>> Currently soft_offline_page() migrates the entire HugeTLB page, then
>> dequeues it from the active list by making it a dangling HugeTLB page
>> which ofc
On 05/13/2017 03:05 AM, Andrew Morton wrote:
> On Wed, 26 Apr 2017 09:27:31 +0530 Anshuman Khandual
> wrote:
>
>> Though migrating gigantic HugeTLB pages does not sound much like real
>> world use case, they can be affected by memory errors. Hence migration
>> at
On 05/10/2017 12:30 AM, Michal Suchanek wrote:
> Arm64 has 256TB address space so fix the test to pass on Arm as well.
>
> Also remove unneeded numaif include.
>
> Signed-off-by: Michal Suchanek
> ---
> tools/testing/selftests/vm/virtual_address_range.c | 36
> --
> 1 file
On 01/09/2018 09:43 PM, Michal Hocko wrote:
> On Tue 09-01-18 17:18:38, Anshuman Khandual wrote:
>> On 01/09/2018 03:42 AM, Michael Ellerman wrote:
>>> Anshuman Khandual writes:
>>>
>>>> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
>>>>> Mi
On 01/30/2018 08:37 AM, Anshuman Khandual wrote:
> @@ -7621,8 +7622,13 @@ static int __alloc_contig_migrate_range(struct
> compact_control *cc,
> &cc->migratepages);
> cc->nr_migratepages -= nr_reclaimed;
On 01/30/2018 01:29 PM, Michal Hocko wrote:
> On Tue 30-01-18 08:37:14, Anshuman Khandual wrote:
>> alloc_contig_range() initiates compaction and eventual migration for
>> the purpose of either CMA or HugeTLB allocation. At present, reason
>> code remains the same MR_CMA for
On 01/30/2018 08:06 PM, Michal Hocko wrote:
> On Tue 30-01-18 10:36:42, Anshuman Khandual wrote:
>> Allocation helper functions for migrate_pages() remmain scattered with
>> similar names making them really confusing. Rename these functions based
>> on the context for the mi
On 01/30/2018 03:12 PM, Michal Hocko wrote:
> On Tue 30-01-18 14:35:12, Michael Ellerman wrote:
>> Michal Hocko writes:
>>
>>> On Mon 29-01-18 11:02:09, Anshuman Khandual wrote:
>>>> On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
>>>>> On 01/
On 01/31/2018 06:49 PM, Michal Hocko wrote:
> On Wed 31-01-18 10:35:38, Anshuman Khandual wrote:
>> On 01/30/2018 03:12 PM, Michal Hocko wrote:
> [...]
>>> Anshuman, could you try to run
>>> sed 's@^@@' /proc/self/smaps
>>> on a system with MAP_FIX
On 02/01/2018 02:02 AM, Michal Hocko wrote:
> On Wed 31-01-18 12:12:17, Andrew Morton wrote:
>> On Wed, 31 Jan 2018 08:58:52 +0100 Michal Hocko wrote:
>>
>>> On Wed 31-01-18 07:55:05, Anshuman Khandual wrote:
>>>> On 01/30/2018 01:29 PM, Michal Hocko w
On 01/03/2018 01:55 PM, Michal Hocko wrote:
> From: Michal Hocko
>
> do_pages_move is supposed to move user defined memory (an array of
> addresses) to the user defined numa nodes (an array of nodes one for
> each address). The user provided status array then contains resulting
> numa node for ea
On 01/05/2018 05:50 AM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of m
On 01/05/2018 02:44 PM, Michal Hocko wrote:
> On Fri 05-01-18 09:22:22, Anshuman Khandual wrote:
> [...]
>> Hi Michal,
>>
>> After slightly modifying your test case (like fixing the page size for
>> powerpc and just doing simple migration from node 0 to 8 instead of
On 01/05/2018 02:16 PM, Michal Hocko wrote:
> On Fri 05-01-18 12:13:17, Anshuman Khandual wrote:
>> On 01/05/2018 05:50 AM, a...@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2018-01-04-16-19 has been uploaded to
[...]
>>>
>>> This tree is p
On 01/07/2018 04:56 PM, Michael Ellerman wrote:
> Michal Hocko writes:
>
>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>> On 01/05/2018 02:16 PM, Michal Hocko wrote:
>> [...]
>>>> Could you give us more information about the failure
On 01/24/2018 02:35 PM, Michal Hocko wrote:
> On Wed 24-01-18 10:39:41, Anshuman Khandual wrote:
>> On 01/23/2018 09:36 PM, Michal Hocko wrote:
>>> On Tue 23-01-18 21:28:28, Anshuman Khandual wrote:
>>>> On 01/23/2018 06:15 PM, Michal Hocko wrote:
>>>>>
On 01/26/2018 07:34 PM, Michal Hocko wrote:
> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
> [...]
>> I tried to instrument mmap_region() for a single instance of 'sed'
>> binary and traced all it's VMA creation. But there is no trace when
>> that
On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
> On 01/26/2018 07:34 PM, Michal Hocko wrote:
>> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
>> [...]
>>> I tried to instrument mmap_region() for a single instance of 'sed'
>>> binary and traced a
instead.
Signed-off-by: Anshuman Khandual
---
include/linux/migrate.h| 1 +
include/trace/events/migrate.h | 3 ++-
mm/page_alloc.c| 14 ++
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index
Allocation helper functions for migrate_pages() remmain scattered with
similar names making them really confusing. Rename these functions based
on the context for the migration and move them all into common migration
header. Functionality remains unchanged.
Signed-off-by: Anshuman Khandual
On 01/09/2018 03:42 AM, Michael Ellerman wrote:
> Anshuman Khandual writes:
>
>> On 01/07/2018 04:56 PM, Michael Ellerman wrote:
>>> Michal Hocko writes:
>>>
>>>> On Sun 07-01-18 12:19:32, Anshuman Khandual wrote:
>>>>> On 01/05/2018
On 04/06/2018 02:48 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2018-04-05 at 21:34 +0300, Michael S. Tsirkin wrote:
>>> In this specific case, because that would make qemu expect an iommu,
>>> and there isn't one.
>>
>>
>> I think that you can set iommu_platform in qemu without an iommu.
>
> No I
On 04/13/2018 02:46 PM, Chintan Pandya wrote:
> Unmap legs do call vunmap_page_range() irrespective of
> debug_pagealloc_enabled() is enabled or not. So, remove
> redundant check and optional vunmap_page_range() routines.
vunmap_page_range() tears down the page table entries and does
not really fl
On 04/13/2018 03:47 PM, Chintan Pandya wrote:
>
>
> On 4/13/2018 3:29 PM, Anshuman Khandual wrote:
>> On 04/13/2018 02:46 PM, Chintan Pandya wrote:
>>> Unmap legs do call vunmap_page_range() irrespective of
>>> debug_pagealloc_enabled() is enabled or not. S
On 04/13/2018 05:03 PM, Chintan Pandya wrote:
> Client can call vunmap with some intermediate 'addr'
> which may not be the start of the VM area. Entire
> unmap code works with vm->vm_start which is proper
> but debug object API is called with 'addr'. This
> could be a problem within debug objects.
On 11/22/2018 11:31 PM, Dave Hansen wrote:
> On 11/22/18 3:52 AM, Anshuman Khandual wrote:
>>>
>>> It sounds like the subset that's being exposed is insufficient for yo
>>> We did that because we think doing anything but a subset in sysfs will
>>> jus
On 11/22/2018 11:38 PM, Dan Williams wrote:
> On Thu, Nov 22, 2018 at 3:52 AM Anshuman Khandual
> wrote:
>>
>>
>>
>> On 11/19/2018 11:07 PM, Dave Hansen wrote:
>>> On 11/18/18 9:44 PM, Anshuman Khandual wrote:
>>>> IIUC NUMA re-work in prin
On 10/23/2018 06:31 PM, Anshuman Khandual wrote:
> This patch series enables HugeTLB migration support for all supported
> huge page sizes at all levels including contiguous bit implementation.
> Following HugeTLB migration support matrix has been enabled with this
> patch
On 11/24/2018 12:51 AM, Dave Hansen wrote:
> On 11/22/18 10:42 PM, Anshuman Khandual wrote:
>> Are we willing to go in the direction for inclusion of a new system
>> call, subset of it appears on sysfs etc ? My primary concern is not
>> how the attribute information app
On 11/24/2018 02:43 AM, Dan Williams wrote:
> On Fri, Nov 23, 2018 at 11:21 AM Dave Hansen wrote:
>>
>> On 11/22/18 10:42 PM, Anshuman Khandual wrote:
>>> Are we willing to go in the direction for inclusion of a new system
>>> call, subset of it appears on sysf
On 11/26/2018 10:50 PM, Dave Hansen wrote:
> On 11/26/18 7:38 AM, Anshuman Khandual wrote:
>> On 11/24/2018 12:51 AM, Dave Hansen wrote:
>>> On 11/22/18 10:42 PM, Anshuman Khandual wrote:
>>>> Are we willing to go in the direction for inclusion of a new system
>
On 11/26/2018 11:38 PM, Dan Williams wrote:
> On Mon, Nov 26, 2018 at 8:42 AM Dave Hansen wrote:
>>
>> On 11/23/18 1:13 PM, Dan Williams wrote:
A new system call makes total sense to me. I have the same concern
about the completeness of what's exposed in sysfs, I just don't see a
>>>
On 11/23/2018 10:45 PM, Dan Williams wrote:
> On Thu, Nov 22, 2018 at 11:11 PM Anshuman Khandual
> wrote:
>>
>>
>>
>> On 11/22/2018 11:38 PM, Dan Williams wrote:
>>> On Thu, Nov 22, 2018 at 3:52 AM Anshuman Khandual
>>> wrote:
>>>&
On 11/19/2018 11:07 PM, Dave Hansen wrote:
> On 11/18/18 9:44 PM, Anshuman Khandual wrote:
>> IIUC NUMA re-work in principle involves these functional changes
>>
>> 1. Enumerating compute and memory nodes in heterogeneous environment
>> (short/medium term)
>
On 11/19/2018 09:16 PM, Keith Busch wrote:
> On Mon, Nov 19, 2018 at 09:05:07AM +0530, Anshuman Khandual wrote:
>> On 11/15/2018 04:19 AM, Keith Busch wrote:
>>> Heterogeneous memory systems provide memory nodes with latency
>>> and bandwidth performance attributes th
On 11/20/2018 04:36 AM, Keith Busch wrote:
> On Mon, Nov 19, 2018 at 09:44:00AM +0530, Anshuman Khandual wrote:
>> On 11/15/2018 04:19 AM, Keith Busch wrote:
>>> System memory may have side caches to help improve access speed. While
>>> the system provided cache is
On 11/30/2018 11:00 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc_le perf)
> failed like this:
>
> bench/numa.c: In function 'bind_to_node':
> bench/numa.c:301:21: error: 'NUMA_NO_NODE' undeclared (first use in this
> function); di
On 11/15/2018 04:19 AM, Keith Busch wrote:
> This series provides a new sysfs representation for heterogeneous
> system memory.
>
> The previous series that was specific to HMAT that this series was based
> on was last posted here: https://lkml.org/lkml/2017/12/13/968
>
> Platforms may provide mu
emerg("name:\"%*s\" ", dentry->d_name.len,
> dentry->d_name.name);
> + }
> + }
> BUILD_BUG_ON(ARRAY_SIZE(pageflag_names) != __NR_PAGEFLAGS + 1);
>
> pr_emerg("flags: %#lx(%pGp)\n", page->flags, &page->flags);
>
Differentiating between anon, ksm mapping and going till dentry information
for file mappings is surely an improvement.
Reviewed-by: Anshuman Khandual
pages))
> - return -EINVAL;
> -
> mem_hotplug_begin();
>
> /* This makes hotplug much easier...and readable.
>
Reviewed-by: Anshuman Khandual
> Signed-off-by: Michal Hocko
Reviewed-by: Anshuman Khandual
On 11/16/2018 02:00 PM, Michal Hocko wrote:
> Hi,
> this has been posted as an RFC [1]. I have screwed during rebasing so
> there were few compilation issues in the previous version. I have also
> integrated review feedback from Andrew and Anshuman.
>
> I have been promissing to improve memory o
0llx] failed\n",
> + pr_debug("memory offlining [mem %#010llx-%#010llx] failed due to %s\n",
>(unsigned long long) start_pfn << PAGE_SHIFT,
> - ((unsigned long long) end_pfn << PAGE_SHIFT) - 1);
> + ((unsigned long long) end_pfn << PAGE_SHIFT) - 1,
> + reason);
> memory_notify(MEM_CANCEL_OFFLINE, &arg);
> /* pushback to free area */
> - undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
> mem_hotplug_done();
> return ret;
> }
>
Reviewed-by: Anshuman Khandual
a/mm/page_alloc.c b/mm/page_alloc.c
> index a919ba5cb3c8..ec2c7916dc2d 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -7845,6 +7845,7 @@ bool has_unmovable_pages(struct zone *zone, struct page
> *page, int count,
> return false;
> unmovable:
> WARN_ON_ONCE(zone_idx(zone) == ZONE_MOVABLE);
> + dump_page(pfn_to_page(pfn+iter), "unmovable page");
> return true;
> }
This seems to have fixed the previous build problem because of the
migrate_pages()
return code. Otherwise looks good.
Reviewed-by: Anshuman Khandual
On 11/16/2018 09:21 PM, Keith Busch wrote:
> On Fri, Nov 16, 2018 at 11:57:58AM +0530, Anshuman Khandual wrote:
>> On 11/15/2018 04:19 AM, Keith Busch wrote:
>>> This series provides a new sysfs representation for heterogeneous
>>> system memory.
>>>
>>
On 11/15/2018 04:19 AM, Keith Busch wrote:
> Memory-only nodes will often have affinity to a compute node, and
> platforms have ways to express that locality relationship.
It may not have a local affinity to any compute node but it might have a
valid NUMA distance from all available compute nod
On 11/15/2018 08:29 PM, Keith Busch wrote:
> On Thu, Nov 15, 2018 at 05:57:10AM -0800, Matthew Wilcox wrote:
>> On Wed, Nov 14, 2018 at 03:49:14PM -0700, Keith Busch wrote:
>>> Memory-only nodes will often have affinity to a compute node, and
>>> platforms have ways to express that locality rela
On 11/15/2018 11:20 PM, Dan Williams wrote:
> On Thu, Nov 15, 2018 at 7:02 AM Keith Busch wrote:
>>
>> On Thu, Nov 15, 2018 at 05:57:10AM -0800, Matthew Wilcox wrote:
>>> On Wed, Nov 14, 2018 at 03:49:14PM -0700, Keith Busch wrote:
Memory-only nodes will often have affinity to a compute no
On 11/17/2018 12:02 AM, Keith Busch wrote:
> On Thu, Nov 15, 2018 at 12:36:54PM -0800, Matthew Wilcox wrote:
>> On Thu, Nov 15, 2018 at 07:59:20AM -0700, Keith Busch wrote:
>>> On Thu, Nov 15, 2018 at 05:57:10AM -0800, Matthew Wilcox wrote:
On Wed, Nov 14, 2018 at 03:49:14PM -0700, Keith Bu
On 11/15/2018 04:19 AM, Keith Busch wrote:
> Heterogeneous memory systems provide memory nodes with latency
> and bandwidth performance attributes that are different from other
> nodes. Create an interface for the kernel to register these attributes
There are other properties like power consump
On 11/15/2018 04:19 AM, Keith Busch wrote:
> System memory may have side caches to help improve access speed. While
> the system provided cache is transparent to the software accessing
> these memory ranges, applications can optimize their own access based
> on cache attributes.
Cache is not a
On 11/16/2018 10:25 PM, Dave Hansen wrote:
> On 11/15/18 10:27 PM, Anshuman Khandual wrote:
>> Not able to see the patches from this series either on the list or on the
>> archive (https://lkml.org/lkml/2018/11/15/331). IIRC last time we discussed
>> about this and the c
On 11/13/2018 05:49 AM, Naoya Horiguchi wrote:
> On Fri, Nov 09, 2018 at 05:03:06PM +0530, Anshuman Khandual wrote:
>>
>>
>> On 11/09/2018 12:17 PM, Naoya Horiguchi wrote:
>>> The new function is a reverse operation of set_hwpoison_free_buddy_page()
>>>
On 11/13/2018 05:46 AM, Naoya Horiguchi wrote:
> Hi Anshuman,
>
> On Fri, Nov 09, 2018 at 03:50:41PM +0530, Anshuman Khandual wrote:
>>
>> On 11/09/2018 12:17 PM, Naoya Horiguchi wrote:
>>> set_hwpoison_free_buddy_page() could fail, then the target page is
>
Stephen Rothwell
Makes sense. Thanks Stephen for taking care of this build failure
more than once.
Reviewed-by: Anshuman Khandual
On 10/31/2018 11:27 PM, Punit Agrawal wrote:
> Stage 2 fault handler marks a page as executable if it is handling an
> execution fault or if it was a permission fault in which case the
> executable bit needs to be preserved.
>
> The logic to decide if the page should be marked executable is
> d
On 11/08/2018 03:59 PM, Michal Hocko wrote:
> [Removing Wen Congyang and Tang Chen from the CC list because their
> emails bounce. It seems that we will never learn about their motivation]
>
> On Thu 08-11-18 11:04:13, Michal Hocko wrote:
>> From: Michal Hocko
>>
>> Per-cpu numa_node provides
On 11/07/2018 03:04 AM, Grygorii Strashko wrote:
> Hi All,
>
> Do anybody tried to use ARM64 RT with 76K pages enabled?
>
> My attempt shows that enabling CONFIG_ARM64_64K_PAGES=y increases latencies
> by ~30%
Depends on what the workload is actually doing. 64K pages should help if
the mapp
On 11/09/2018 12:17 PM, Naoya Horiguchi wrote:
> memory_failure() forks to memory_failure_hugetlb() for hugetlb pages,
> so a PageHuge() check after the fork should not be necessary.
>
> Signed-off-by: Naoya Horiguchi
Pretty straightforward.
Reviewed-by: Anshuman Khandual
On 11/09/2018 12:17 PM, Naoya Horiguchi wrote:
> set_hwpoison_free_buddy_page() could fail, then the target page is
> finally not isolated, so it's better to report -EBUSY for userspace
> to know the failure and chance of retry.
>
IIUC set_hwpoison_free_buddy_page() could only fail if the page
> --- v4.19-mmotm-2018-10-30-16-08/mm/sparse.c
> +++ v4.19-mmotm-2018-10-30-16-08_patched/mm/sparse.c
> @@ -726,7 +726,7 @@ static void clear_hwpoisoned_pages(struct page *memmap,
> int nr_pages)
>
> for (i = 0; i < nr_pages; i++) {
> if (PageHWPoison(&memmap[i])) {
> - atomic_long_sub(1, &num_poisoned_pages);
> + num_poisoned_pages_dec();
> ClearPageHWPoison(&memmap[i]);
> }
> }
>
Otherwise looks good.
Reviewed-by: Anshuman Khandual
On 11/09/2018 12:17 PM, Naoya Horiguchi wrote:
> Currently madvise_inject_error() pins the target page when calling
> memory error handler, but it's not good because the refcount is just
> an artifact of error injector and mock nothing about hw error itself.
> IOW, pinning the error page is part
On 11/09/2018 01:29 PM, Michal Hocko wrote:
> On Fri 09-11-18 09:12:09, Anshuman Khandual wrote:
>>
>>
>> On 11/08/2018 03:59 PM, Michal Hocko wrote:
>>> [Removing Wen Congyang and Tang Chen from the CC list because their
>>> emails bounce. It see
On 11/09/2018 12:17 PM, Naoya Horiguchi wrote:
> The new function is a reverse operation of set_hwpoison_free_buddy_page()
> to adjust unpoison_memory() to the new semantics.
>
> Signed-off-by: Naoya Horiguchi
snip
> +
> +/*
> + * Reverse operation of set_hwpoison_free_buddy_page(), which is
On 05/24/2018 01:30 PM, Michal Hocko wrote:
> On Thu 24-05-18 08:52:14, Anshuman Khandual wrote:
>> On 05/23/2018 07:36 PM, Michal Hocko wrote:
>>> On Wed 23-05-18 19:15:51, Anshuman Khandual wrote:
>>>> On 05/23/2018 06:25 PM, Michal Hocko wrote:
>>>
Hexagon arch does not seem to have subscribed to _HAVE_COLOR_ZERO_PAGE
framework. Hence zero_page_mask variable is not needed.
Signed-off-by: Anshuman Khandual
---
I will have to request some one with hexagon system to compile and
test this patch. Dont have access to hardware.
arch/hexagon
On 12/03/2018 12:30 PM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm tree, today's linux-next build (powerpc_le perf)
> failed like this:
>
> bench/numa.c:37:10: fatal error: linux/numa.h: No such file or directory
> #include
> ^~
>
> Caused by patch
2M NA 1G
16K:NA32M NA
64K:NA 512M NA
Reviewed-by: Naoya Horiguchi
Reviewed-by: Steve Capper
Acked-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
arch/arm64/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64
Reviewed-by: Steve Capper
Acked-by: Michal Hocko
Signed-off-by: Anshuman Khandual
---
include/linux/hugetlb.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 1b858d7..70bcd89 100644
--- a/include/linux/hugetlb.h
+++ b
/190)
- Added a new patch which differentiates migratability and movability
of huge pages and implements hugepage_movable_supported() function
as suggested by Michal Hocko.
Anshuman Khandual (5):
mm/hugetlb: Distinguish between migratability and movability
mm/hugetlb: Enable PUD level huge
other enhanced checks.
Reviewed-by: Steve Capper
Reviewed-by: Naoya Horiguchi
Suggested-by: Michal Hocko
Acked-by: Michal Hocko
Signed-off-by: Anshuman Khandual
---
include/linux/hugetlb.h | 30 ++
mm/hugetlb.c| 2 +-
mm/migrate.c| 2
comprehensive set of huge page sizes.
Reviewed-by: Naoya Horiguchi
Reviewed-by: Steve Capper
Acked-by: Michal Hocko
Signed-off-by: Anshuman Khandual
---
include/linux/hugetlb.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux
Horiguchi
Reviewed-by: Steve Capper
Acked-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
arch/arm64/include/asm/hugetlb.h | 5 +
arch/arm64/mm/hugetlbpage.c | 20
2 files changed, 25 insertions(+)
diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64
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
[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
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/22/2018 04:58 AM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-12-21-15-28 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot o
On 01/07/2019 02:13 PM, Michal Hocko wrote:
> Hi,
>
> On Mon 07-01-19 13:02:31, Anshuman Khandual wrote:
>> On 12/22/2018 04:58 AM, a...@linux-foundation.org wrote:
> [...]
>>> A git tree which contains the memory management portion of this tree is
>>> ma
On 01/08/2019 07:41 AM, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (native
> perf) failed like this:
>
> bench/numa.c: In function 'bind_to_node':
> bench/numa.c:301:21: error: 'NUMA_NO_NODE' undeclared (first use in this
> function)
On 12/18/2018 01:54 PM, Anshuman Khandual wrote:
> This patch series enables HugeTLB migration support for all supported
> huge page sizes at all levels including contiguous bit implementation.
> Following HugeTLB migration support matrix has been enabled with this
> patch
differentiating the two while walking the page table.
Fixes: 616b8371539a6 ("mm: thp: enable thp migration in generic path")
Signed-off-by: Anshuman Khandual
---
On X86, pmd_trans_huge() and is_pmd_migration_entry() are always mutually
exclusive which makes the current conditional bloc
On 10/09/2018 06:34 PM, Kirill A. Shutemov wrote:
> On Tue, Oct 09, 2018 at 09:28:58AM +0530, Anshuman Khandual wrote:
>> A normal mapped THP page at PMD level should be correctly differentiated
>> from a PMD migration entry while walking the page table. A mapped THP would
>&g
On 10/09/2018 07:44 PM, Michal Hocko wrote:
> On Fri 05-10-18 13:04:43, Anshuman Khandual wrote:
>> Does the following sound close enough to what you are looking for ?
>
> I do not think so
Okay.
>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
&
On 10/09/2018 07:28 PM, Zi Yan wrote:
> cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE for x86
> PMD migration entry check)
>
> On 8 Oct 2018, at 23:58, Anshuman Khandual wrote:
>
>> A normal mapped THP page at PMD level should be correctly
101 - 200 of 1979 matches
Mail list logo
