* Re: [RFC 01/10] x86/mm: Reimplement flush_tlb_page() using flush_tlb_mm_range()
From: Andy Lutomirski @ 2017-05-12 3:35 UTC (permalink / raw)
To: Borislav Petkov
Cc: Andy Lutomirski, X86 ML, linux-kernel@vger.kernel.org,
Linus Torvalds, Andrew Morton, Mel Gorman, linux-mm@kvack.org,
Rik van Riel, Dave Hansen, Nadav Amit, Michal Hocko
In-Reply-To: <20170511174128.rp7dwckpci4gqsxy@pd.tnic>
On Thu, May 11, 2017 at 10:41 AM, Borislav Petkov <bp@suse.de> wrote:
>> +{
>> + flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, 0);
>
> VM_NONE);
>
Fixed, although this won't have any effect.
--Andy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] mm: per-cgroup memory reclaim stats
From: Balbir Singh @ 2017-05-12 2:25 UTC (permalink / raw)
To: Roman Gushchin, Johannes Weiner
Cc: Tejun Heo, Li Zefan, Michal Hocko, Vladimir Davydov, cgroups,
linux-doc, linux-kernel, linux-mm
In-Reply-To: <1494530183-30808-1-git-send-email-guro@fb.com>
On Thu, 2017-05-11 at 20:16 +0100, Roman Gushchin wrote:
> Track the following reclaim counters for every memory cgroup:
> PGREFILL, PGSCAN, PGSTEAL, PGACTIVATE, PGDEACTIVATE, PGLAZYFREE and
> PGLAZYFREED.
>
> These values are exposed using the memory.stats interface of cgroup v2.
The changelog could also describe what is currently there and what
is missing. Is there a user space program that uses the newly exported
values? Or is this just for consistency of stats?
>
> The meaning of each value is the same as for global counters,
> available using /proc/vmstat.
>
> Also, for consistency, rename mem_cgroup_count_vm_event() to
> count_memcg_event_mm().
>
I still prefer the mem_cgroup_count_vm_event() name, or memcg_count_vm_event(),
the namespace upfront makes it easier to parse where to look for the the
implementation and also grep. In any case the rename should be independent
patch, but I don't like the name you've proposed.
> Signed-off-by: Roman Gushchin <guro@fb.com>
> Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Johannes Weiner <hannes@cmpxchg.org>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Li Zefan <lizefan@huawei.com>
> Cc: Michal Hocko <mhocko@kernel.org>
> Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
> Cc: cgroups@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-mm@kvack.org
> ---
> Documentation/cgroup-v2.txt | 28 ++++++++++++++++++++++++++
> fs/dax.c | 2 +-
> fs/ncpfs/mmap.c | 2 +-
> include/linux/memcontrol.h | 48 ++++++++++++++++++++++++++++++++++++++++++---
> mm/filemap.c | 2 +-
> mm/memcontrol.c | 10 ++++++++++
> mm/memory.c | 4 ++--
> mm/shmem.c | 3 +--
> mm/swap.c | 1 +
> mm/vmscan.c | 30 +++++++++++++++++++++-------
> 10 files changed, 113 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index e50b95c..5804355 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -918,6 +918,34 @@ PAGE_SIZE multiple when read back.
>
> Number of major page faults incurred
>
> + pgrefill
> +
> + Amount of scanned pages (in an active LRU list)
> +
> + pgscan
> +
> + Amount of scanned pages (in an inactive LRU list)
> +
> + pgsteal
> +
> + Amount of reclaimed pages
> +
> + pgactivate
> +
> + Amount of pages moved to the active LRU list
> +
> + pgdeactivate
> +
> + Amount of pages moved to the inactive LRU lis
> +
> + pglazyfree
> +
> + Amount of pages postponed to be freed under memory pressure
> +
> + pglazyfreed
> +
> + Amount of reclaimed lazyfree pages
> +
> memory.swap.current
>
> A read-only single value file which exists on non-root
> diff --git a/fs/dax.c b/fs/dax.c
> index 66d7906..9aac521d 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1230,7 +1230,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
> case IOMAP_MAPPED:
> if (iomap.flags & IOMAP_F_NEW) {
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> major = VM_FAULT_MAJOR;
> }
> error = dax_insert_mapping(mapping, iomap.bdev, iomap.dax_dev,
> diff --git a/fs/ncpfs/mmap.c b/fs/ncpfs/mmap.c
> index 0c3905e..6719c0b 100644
> --- a/fs/ncpfs/mmap.c
> +++ b/fs/ncpfs/mmap.c
> @@ -89,7 +89,7 @@ static int ncp_file_mmap_fault(struct vm_fault *vmf)
> * -- nyc
> */
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> return VM_FAULT_MAJOR;
> }
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 899949b..b2a5b1c 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -357,6 +357,17 @@ static inline unsigned short mem_cgroup_id(struct mem_cgroup *memcg)
> }
> struct mem_cgroup *mem_cgroup_from_id(unsigned short id);
>
> +static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
mem_cgroup_from_lruvec()?
> +{
> + struct mem_cgroup_per_node *mz;
> +
> + if (mem_cgroup_disabled())
> + return NULL;
> +
> + mz = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
> + return mz->memcg;
> +}
> +
> /**
> * parent_mem_cgroup - find the accounting parent of a memcg
> * @memcg: memcg whose parent to find
> @@ -546,8 +557,23 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order,
> gfp_t gfp_mask,
> unsigned long *total_scanned);
>
> -static inline void mem_cgroup_count_vm_event(struct mm_struct *mm,
> - enum vm_event_item idx)
> +static inline void count_memcg_events(struct mem_cgroup *memcg,
> + enum vm_event_item idx,
> + unsigned long count)
> +{
> + if (!mem_cgroup_disabled())
> + this_cpu_add(memcg->stat->events[idx], count);
> +}
> +
> +static inline void count_memcg_page_event(struct page *page,
> + enum memcg_stat_item idx)
> +{
> + if (page->mem_cgroup)
> + count_memcg_events(page->mem_cgroup, idx, 1);
> +}
> +
> +static inline void count_memcg_event_mm(struct mm_struct *mm,
> + enum vm_event_item idx)
> {
> struct mem_cgroup *memcg;
>
> @@ -675,6 +701,11 @@ static inline struct mem_cgroup *mem_cgroup_from_id(unsigned short id)
> return NULL;
> }
>
> +static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
> +{
> + return NULL;
> +}
> +
> static inline bool mem_cgroup_online(struct mem_cgroup *memcg)
> {
> return true;
> @@ -789,8 +820,19 @@ static inline void mem_cgroup_split_huge_fixup(struct page *head)
> {
> }
>
> +static inline void count_memcg_events(struct mem_cgroup *memcg,
> + enum vm_event_item idx,
> + unsigned long count)
> +{
> +}
> +
> +static inline void count_memcg_page_event(struct page *page,
> + enum memcg_stat_item idx)
> +{
> +}
> +
> static inline
> -void mem_cgroup_count_vm_event(struct mm_struct *mm, enum vm_event_item idx)
> +void count_memcg_event_mm(struct mm_struct *mm, enum vm_event_item idx)
> {
> }
> #endif /* CONFIG_MEMCG */
> diff --git a/mm/filemap.c b/mm/filemap.c
> index b7b973b..d640613 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2226,7 +2226,7 @@ int filemap_fault(struct vm_fault *vmf)
> /* No page in the page cache at all */
> do_sync_mmap_readahead(vmf->vma, ra, file, offset);
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
> ret = VM_FAULT_MAJOR;
> retry_find:
> page = find_get_page(mapping, offset);
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index ff73899..0cfa0aa 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5231,6 +5231,16 @@ static int memory_stat_show(struct seq_file *m, void *v)
> seq_printf(m, "pgfault %lu\n", events[PGFAULT]);
> seq_printf(m, "pgmajfault %lu\n", events[PGMAJFAULT]);
>
> + seq_printf(m, "pgrefill %lu\n", events[PGREFILL]);
> + seq_printf(m, "pgscan %lu\n", events[PGSCAN_KSWAPD] +
> + events[PGSCAN_DIRECT]);
> + seq_printf(m, "pgsteal %lu\n", events[PGSTEAL_KSWAPD] +
> + events[PGSTEAL_DIRECT]);
> + seq_printf(m, "pgactivate %lu\n", events[PGACTIVATE]);
> + seq_printf(m, "pgdeactivate %lu\n", events[PGDEACTIVATE]);
> + seq_printf(m, "pglazyfree %lu\n", events[PGLAZYFREE]);
> + seq_printf(m, "pglazyfreed %lu\n", events[PGLAZYFREED]);
> +
> seq_printf(m, "workingset_refault %lu\n",
> stat[WORKINGSET_REFAULT]);
> seq_printf(m, "workingset_activate %lu\n",
> diff --git a/mm/memory.c b/mm/memory.c
> index 6ff5d72..5aa1348 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2719,7 +2719,7 @@ int do_swap_page(struct vm_fault *vmf)
> /* Had to read the page from swap area: Major fault */
> ret = VM_FAULT_MAJOR;
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vma->vm_mm, PGMAJFAULT);
> } else if (PageHWPoison(page)) {
> /*
> * hwpoisoned dirty swapcache pages are kept for killing
> @@ -3855,7 +3855,7 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> __set_current_state(TASK_RUNNING);
>
> count_vm_event(PGFAULT);
> - mem_cgroup_count_vm_event(vma->vm_mm, PGFAULT);
> + count_memcg_event_mm(vma->vm_mm, PGFAULT);
>
> /* do counter updates before entering really critical section. */
> check_sync_rss_stat(current);
> diff --git a/mm/shmem.c b/mm/shmem.c
> index e67d6ba..8cf16fb 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1645,8 +1645,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
> if (fault_type) {
> *fault_type |= VM_FAULT_MAJOR;
> count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(charge_mm,
> - PGMAJFAULT);
> + count_memcg_event_mm(charge_mm, PGMAJFAULT);
> }
> /* Here we actually start the io */
> page = shmem_swapin(swap, gfp, info, index);
> diff --git a/mm/swap.c b/mm/swap.c
> index 98d08b4..4f44dbd 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -591,6 +591,7 @@ static void lru_lazyfree_fn(struct page *page, struct lruvec *lruvec,
> add_page_to_lru_list(page, lruvec, LRU_INACTIVE_FILE);
>
> __count_vm_events(PGLAZYFREE, hpage_nr_pages(page));
> + count_memcg_page_event(page, PGLAZYFREE);
> update_page_reclaim_stat(lruvec, 1, 0);
> }
> }
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 5ebf468..76e98b5 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1266,6 +1266,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
> }
>
> count_vm_event(PGLAZYFREED);
> + count_memcg_page_event(page, PGLAZYFREED);
> } else if (!mapping || !__remove_mapping(mapping, page, true))
> goto keep_locked;
> /*
> @@ -1295,6 +1296,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
> if (!PageMlocked(page)) {
> SetPageActive(page);
> pgactivate++;
> + count_memcg_page_event(page, PGACTIVATE);
> }
> keep_locked:
> unlock_page(page);
> @@ -1725,11 +1727,16 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
> __mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, nr_taken);
> reclaim_stat->recent_scanned[file] += nr_taken;
>
> - if (global_reclaim(sc)) {
> - if (current_is_kswapd())
> + if (current_is_kswapd()) {
> + if (global_reclaim(sc))
> __count_vm_events(PGSCAN_KSWAPD, nr_scanned);
> - else
> + count_memcg_events(lruvec_memcg(lruvec), PGSCAN_KSWAPD,
> + nr_scanned);
> + } else {
> + if (global_reclaim(sc))
> __count_vm_events(PGSCAN_DIRECT, nr_scanned);
> + count_memcg_events(lruvec_memcg(lruvec), PGSCAN_DIRECT,
> + nr_scanned);
> }
> spin_unlock_irq(&pgdat->lru_lock);
>
> @@ -1741,11 +1748,16 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
>
> spin_lock_irq(&pgdat->lru_lock);
>
> - if (global_reclaim(sc)) {
> - if (current_is_kswapd())
> + if (current_is_kswapd()) {
> + if (global_reclaim(sc))
> __count_vm_events(PGSTEAL_KSWAPD, nr_reclaimed);
> - else
> + count_memcg_events(lruvec_memcg(lruvec), PGSTEAL_KSWAPD,
> + nr_reclaimed);
Has the else gone missing? What happens if it's global_reclaim(), do
we still account the count in memcg?
> + } else {
> + if (global_reclaim(sc))
> __count_vm_events(PGSTEAL_DIRECT, nr_reclaimed);
> + count_memcg_events(lruvec_memcg(lruvec), PGSTEAL_DIRECT,
> + nr_reclaimed);
It sounds like memcg accumlates both global and memcg reclaim driver
counts -- is this what we want?
> }
>
> putback_inactive_pages(lruvec, &page_list);
> @@ -1890,8 +1902,11 @@ static unsigned move_active_pages_to_lru(struct lruvec *lruvec,
> }
> }
>
> - if (!is_active_lru(lru))
> + if (!is_active_lru(lru)) {
> __count_vm_events(PGDEACTIVATE, nr_moved);
> + count_memcg_events(lruvec_memcg(lruvec), PGDEACTIVATE,
> + nr_moved);
> + }
>
> return nr_moved;
> }
> @@ -1929,6 +1944,7 @@ static void shrink_active_list(unsigned long nr_to_scan,
> reclaim_stat->recent_scanned[file] += nr_taken;
>
> __count_vm_events(PGREFILL, nr_scanned);
> + count_memcg_events(lruvec_memcg(lruvec), PGREFILL, nr_scanned);
>
> spin_unlock_irq(&pgdat->lru_lock);
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH 2/2] mm: swap: move anonymous THP split logic to vmscan
From: Minchan Kim @ 2017-05-12 2:21 UTC (permalink / raw)
To: Huang Ying
Cc: Andrew Morton, Johannes Weiner, linux-kernel, linux-mm,
Minchan Kim
In-Reply-To: <1494555684-11982-1-git-send-email-minchan@kernel.org>
The add_to_swap aims to allocate swap_space(ie, swap slot and
swapcache) so if it fails due to lack of space in case of THP
or something(hdd swap but tries THP swapout) *caller* rather
than add_to_swap itself should split the THP page and retry it
with base page which is more natural.
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
include/linux/swap.h | 4 ++--
mm/swap_state.c | 23 ++++++-----------------
mm/vmscan.c | 17 ++++++++++++++++-
3 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 8f12f67e869f..87cca2169d44 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -359,7 +359,7 @@ extern struct address_space *swapper_spaces[];
>> SWAP_ADDRESS_SPACE_SHIFT])
extern unsigned long total_swapcache_pages(void);
extern void show_swap_cache_info(void);
-extern int add_to_swap(struct page *, struct list_head *list);
+extern int add_to_swap(struct page *);
extern int add_to_swap_cache(struct page *, swp_entry_t, gfp_t);
extern int __add_to_swap_cache(struct page *page, swp_entry_t entry);
extern void __delete_from_swap_cache(struct page *);
@@ -479,7 +479,7 @@ static inline struct page *lookup_swap_cache(swp_entry_t swp)
return NULL;
}
-static inline int add_to_swap(struct page *page, struct list_head *list)
+static inline int add_to_swap(struct page *page)
{
return 0;
}
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 0ad214d7a7ad..9c71b6b2562f 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -184,7 +184,7 @@ void __delete_from_swap_cache(struct page *page)
* Allocate swap space for the page and add the page to the
* swap cache. Caller needs to hold the page lock.
*/
-int add_to_swap(struct page *page, struct list_head *list)
+int add_to_swap(struct page *page)
{
swp_entry_t entry;
int err;
@@ -192,12 +192,12 @@ int add_to_swap(struct page *page, struct list_head *list)
VM_BUG_ON_PAGE(!PageLocked(page), page);
VM_BUG_ON_PAGE(!PageUptodate(page), page);
-retry:
entry = get_swap_page(page);
if (!entry.val)
- goto fail;
+ return 0;
+
if (mem_cgroup_try_charge_swap(page, entry))
- goto fail_free;
+ goto fail;
/*
* Radix-tree node allocations from PF_MEMALLOC contexts could
@@ -218,23 +218,12 @@ int add_to_swap(struct page *page, struct list_head *list)
* add_to_swap_cache() doesn't return -EEXIST, so we can safely
* clear SWAP_HAS_CACHE flag.
*/
- goto fail_free;
-
- if (PageTransHuge(page)) {
- err = split_huge_page_to_list(page, list);
- if (err) {
- delete_from_swap_cache(page);
- return 0;
- }
- }
+ goto fail;
return 1;
-fail_free:
- put_swap_page(page, entry);
fail:
- if (PageTransHuge(page) && !split_huge_page_to_list(page, list))
- goto retry;
+ put_swap_page(page, entry);
return 0;
}
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 57268c0c8fcf..767e20856080 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1125,8 +1125,23 @@ static unsigned long shrink_page_list(struct list_head *page_list,
!PageSwapCache(page)) {
if (!(sc->gfp_mask & __GFP_IO))
goto keep_locked;
- if (!add_to_swap(page, page_list))
+ if (!add_to_swap(page)) {
+ if (!PageTransHuge(page))
+ goto activate_locked;
+ /* Split THP and swap individual base pages */
+ if (split_huge_page_to_list(page, page_list))
+ goto activate_locked;
+ if (!add_to_swap(page))
+ goto activate_locked;
+ }
+
+ /* XXX: We don't support THP writes */
+ if (PageTransHuge(page) &&
+ split_huge_page_to_list(page, page_list)) {
+ delete_from_swap_cache(page);
goto activate_locked;
+ }
+
may_enter_fs = 1;
/* Adding to swap updated mapping */
--
2.7.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH 1/2] mm: swap: unify swap slot free functions to put_swap_page
From: Minchan Kim @ 2017-05-12 2:21 UTC (permalink / raw)
To: Huang Ying
Cc: Andrew Morton, Johannes Weiner, linux-kernel, linux-mm,
Minchan Kim
In-Reply-To: <87h90sb4jq.fsf@yhuang-dev.intel.com>
Now, get_swap_page takes struct page and allocates swap space
according to page size(ie, normal or THP) so it would be more
cleaner to introduce put_swap_page which is a counter function
of get_swap_page. Then, it calls right swap slot free function
depending on page's size.
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
include/linux/swap.h | 4 ++--
mm/shmem.c | 2 +-
mm/swap_state.c | 13 +++----------
mm/swapfile.c | 8 ++++++++
mm/vmscan.c | 2 +-
5 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index b60fea3748f8..8f12f67e869f 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -393,6 +393,7 @@ static inline long get_nr_swap_pages(void)
extern void si_swapinfo(struct sysinfo *);
extern swp_entry_t get_swap_page(struct page *page);
+extern void put_swap_page(struct page *page, swp_entry_t entry);
extern swp_entry_t get_swap_page_of_type(int);
extern int get_swap_pages(int n, bool cluster, swp_entry_t swp_entries[]);
extern int add_swap_count_continuation(swp_entry_t, gfp_t);
@@ -400,7 +401,6 @@ extern void swap_shmem_alloc(swp_entry_t);
extern int swap_duplicate(swp_entry_t);
extern int swapcache_prepare(swp_entry_t);
extern void swap_free(swp_entry_t);
-extern void swapcache_free(swp_entry_t);
extern void swapcache_free_entries(swp_entry_t *entries, int n);
extern int free_swap_and_cache(swp_entry_t);
extern int swap_type_of(dev_t, sector_t, struct block_device **);
@@ -459,7 +459,7 @@ static inline void swap_free(swp_entry_t swp)
{
}
-static inline void swapcache_free(swp_entry_t swp)
+static inline void put_swap_page(struct page *page, swp_entry_t swp)
{
}
diff --git a/mm/shmem.c b/mm/shmem.c
index 29948d7da172..82158edaefdb 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1326,7 +1326,7 @@ static int shmem_writepage(struct page *page, struct writeback_control *wbc)
mutex_unlock(&shmem_swaplist_mutex);
free_swap:
- swapcache_free(swap);
+ put_swap_page(page, swap);
redirty:
set_page_dirty(page);
if (wbc->for_reclaim)
diff --git a/mm/swap_state.c b/mm/swap_state.c
index 16ff89d058f4..0ad214d7a7ad 100644
--- a/mm/swap_state.c
+++ b/mm/swap_state.c
@@ -231,10 +231,7 @@ int add_to_swap(struct page *page, struct list_head *list)
return 1;
fail_free:
- if (PageTransHuge(page))
- swapcache_free_cluster(entry);
- else
- swapcache_free(entry);
+ put_swap_page(page, entry);
fail:
if (PageTransHuge(page) && !split_huge_page_to_list(page, list))
goto retry;
@@ -259,11 +256,7 @@ void delete_from_swap_cache(struct page *page)
__delete_from_swap_cache(page);
spin_unlock_irq(&address_space->tree_lock);
- if (PageTransHuge(page))
- swapcache_free_cluster(entry);
- else
- swapcache_free(entry);
-
+ put_swap_page(page, entry);
page_ref_sub(page, hpage_nr_pages(page));
}
@@ -415,7 +408,7 @@ struct page *__read_swap_cache_async(swp_entry_t entry, gfp_t gfp_mask,
* add_to_swap_cache() doesn't return -EEXIST, so we can safely
* clear SWAP_HAS_CACHE flag.
*/
- swapcache_free(entry);
+ put_swap_page(new_page, entry);
} while (err != -ENOMEM);
if (new_page)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 596306272059..b65e49428090 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1182,6 +1182,14 @@ void swapcache_free_cluster(swp_entry_t entry)
}
#endif /* CONFIG_THP_SWAP */
+void put_swap_page(struct page *page, swp_entry_t entry)
+{
+ if (!PageTransHuge(page))
+ swapcache_free(entry);
+ else
+ swapcache_free_cluster(entry);
+}
+
static int swp_entry_cmp(const void *ent1, const void *ent2)
{
const swp_entry_t *e1 = ent1, *e2 = ent2;
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 5ebf468c5429..57268c0c8fcf 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -708,7 +708,7 @@ static int __remove_mapping(struct address_space *mapping, struct page *page,
mem_cgroup_swapout(page, swap);
__delete_from_swap_cache(page);
spin_unlock_irqrestore(&mapping->tree_lock, flags);
- swapcache_free(swap);
+ put_swap_page(page, swap);
} else {
void (*freepage)(struct page *);
void *shadow = NULL;
--
2.7.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH v7 0/7] Introduce ZONE_CMA
From: Joonsoo Kim @ 2017-05-12 2:00 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Rik van Riel, Johannes Weiner, mgorman,
Laura Abbott, Minchan Kim, Marek Szyprowski, Michal Nazarewicz,
Aneesh Kumar K . V, Vlastimil Babka, Russell King, Will Deacon,
linux-mm, linux-kernel, kernel-team
In-Reply-To: <20170511091304.GH26782@dhcp22.suse.cz>
On Thu, May 11, 2017 at 11:13:04AM +0200, Michal Hocko wrote:
> On Thu 11-05-17 11:12:43, Joonsoo Kim wrote:
> > Sorry for the late response. I was on a vacation.
> >
> > On Tue, May 02, 2017 at 03:32:29PM +0200, Michal Hocko wrote:
> > > On Tue 02-05-17 13:01:32, Joonsoo Kim wrote:
> > > > On Thu, Apr 27, 2017 at 05:06:36PM +0200, Michal Hocko wrote:
> > > [...]
> > > > > I see this point and I agree that using a specific zone might be a
> > > > > _nicer_ solution in the end but you have to consider another aspects as
> > > > > well. The main one I am worried about is a long term maintainability.
> > > > > We are really out of page flags and consuming one for a rather specific
> > > > > usecase is not good. Look at ZONE_DMA. I am pretty sure that almost
> > > > > no sane HW needs 16MB zone anymore, yet we have hard time to get rid
> > > > > of it and so we have that memory laying around unused all the time
> > > > > and blocking one page flag bit. CMA falls into a similar category
> > > > > AFAIU. I wouldn't be all that surprised if a future HW will not need CMA
> > > > > allocations in few years, yet we will have to fight to get rid of it
> > > > > like we do with ZONE_DMA. And not only that. We will also have to fight
> > > > > finding page flags for other more general usecases in the meantime.
> > > >
> > > > This maintenance problem is inherent. This problem exists even if we
> > > > uses MIGRATETYPE approach. We cannot remove many hooks for CMA if a
> > > > future HW will not need CMA allocation in few years. The only
> > > > difference is that one takes single zone bit only for CMA user and the
> > > > other approach takes many hooks that we need to take care about it all
> > > > the time.
> > >
> > > And I consider this a big difference. Because while hooks are not nice
> > > they will affect CMA users (in a sense of bugs/performance etc.). While
> > > an additional bit consumed will affect potential future and more generic
> > > features.
> >
> > Because these hooks are so tricky and are spread on many places,
> > bugs about these hooks can be made by *non-CMA* user and they hurt
> > *CMA* user. These hooks could also delay non-CMA user's development speed
> > since there are many hooks about CMA and understanding how CMA is managed
> > is rather difficult.
>
> Than make those hooks easier to maintain. Seriously this is a
> non-argument.
I can't understand what you said here. With zone approach, someone who
isn't related to CMA don't need to understand how CMA is managed.
>
> [...]
>
> > > And all this can be isolated to CMA specific hooks with mostly minimum
> > > impact to most users. I hear you saying that zone approach is more natural
> > > and I would agree if we wouldn't have to care about the number of zones.
> >
> > I attach a solution about one more bit in page flags although I don't
> > agree with your opinion that additional bit is no-go approach. Just
> > note that we have already used three bits for zone encoding in some
> > configuration due to ZONE_DEVICE.
>
> I am absolutely not happy about ZONE_DEVICE but there is _no_ other
> viable solution right now. I know that people behind this are still
> considering struct page over direct pfn usage but they are not in the
> same situation as CMA which _can_ work without additional zone.
IIUC, ZONE_DEVICE can reuse the other zone and migratetype. What
they need is just struct page and separate zone is not necessarily needed.
The other thing that they want is to distinguish if the page is for
the ZONE_DEVICE memory or not so it can use similar approach with CMA.
IMHO, there is almost nothing that _cannot_ work in S/W world. What we
need to consider is just trade-off. So, please don't say impossibility
again.
>
> If you _really_ insist on using zone for CMA then reuse ZONE_MOVABLE.
> I absolutely miss why do you push a specialized zone so hard.
As I said before, there is no fundamental issue to reuse ZONE_MOVABLE.
I just don't want to reuse it because they have a different
characteristic. In MM subsystem context, their characteristic is the same.
However, CMA memory should be used for the device in runtime so more
allocation guarantee is needed. See the offline_pages() in
mm/memory_hotplug.c. They can bear in 120 sec to offline the
memory but CMA memory can't.
And, this is a design issue. I don't want to talk about why should we
pursuit the good design. Originally, ZONE exists to manage different
type of memory. Migratetype is not for that purpose. Using separate
zone fits the original purpose. Mixing them would be a bad design and
we would esaily encounter the unexpected problem in the future.
>
> [...]
> > > No, but I haven't heard any single argument that those bugs are
> > > impossible to fix with the current approach. They might be harder to fix
> > > but if I can chose between harder for CMA and harder for other more
> > > generic HW independent features I will go for the first one. And do not
> > > take me wrong, I have nothing against CMA as such. It solves a real life
> > > problem. I just believe it doesn't deserve to consume a new bit in page
> > > flags because that is just too scarce resource.
> >
> > As I mentioned above, I think that maintenance overhead due to CMA
> > deserves to consume a new bit in page flags. It also provide us
> > extendability to introduce more zones in the future.
> >
> > Anyway, this value-judgement is subjective so I guess that we
> > cannot agree with each other. To solve your concern,
> > I make following solution. Please let me know your opinion about this.
> > This patch can be applied on top of my ZONE_CMA series.
>
> I don not think this makes situation any easier or more acceptable for
> merging.
Please say the reason. This implementation don't use additional bit in
page flags that you concerned about. And, there is no performance
regression at least in my simple test.
> But I feel we are looping without much progress. So let me NAK this
> until it is _proven_ that the current code is unfixable nor ZONE_MOVABLE
> can be reused
I want to open all the possibilty so could you check that ZONE_MOVABLE
can be overlapped with other zones? IIRC, your rework doesn't allow
it.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH -mm -v10 1/3] mm, THP, swap: Delay splitting THP during swap out
From: Minchan Kim @ 2017-05-12 1:34 UTC (permalink / raw)
To: Johannes Weiner
Cc: Huang, Ying, Andrew Morton, linux-mm, linux-kernel,
Andrea Arcangeli, Ebru Akagunduz, Michal Hocko, Tejun Heo,
Hugh Dickins, Shaohua Li, Rik van Riel, cgroups
In-Reply-To: <20170511104058.GD6244@cmpxchg.org>
Hi Hannes,
On Thu, May 11, 2017 at 06:40:58AM -0400, Johannes Weiner wrote:
> On Thu, May 11, 2017 at 10:22:13AM +0900, Minchan Kim wrote:
> > On Thu, May 11, 2017 at 08:25:56AM +0900, Minchan Kim wrote:
> > > On Wed, May 10, 2017 at 09:56:54AM -0400, Johannes Weiner wrote:
> > > > Hi Michan,
> > > >
> > > > On Tue, May 02, 2017 at 08:53:32AM +0900, Minchan Kim wrote:
> > > > > @@ -1144,7 +1144,7 @@ void swap_free(swp_entry_t entry)
> > > > > /*
> > > > > * Called after dropping swapcache to decrease refcnt to swap entries.
> > > > > */
> > > > > -void swapcache_free(swp_entry_t entry)
> > > > > +void __swapcache_free(swp_entry_t entry)
> > > > > {
> > > > > struct swap_info_struct *p;
> > > > >
> > > > > @@ -1156,7 +1156,7 @@ void swapcache_free(swp_entry_t entry)
> > > > > }
> > > > >
> > > > > #ifdef CONFIG_THP_SWAP
> > > > > -void swapcache_free_cluster(swp_entry_t entry)
> > > > > +void __swapcache_free_cluster(swp_entry_t entry)
> > > > > {
> > > > > unsigned long offset = swp_offset(entry);
> > > > > unsigned long idx = offset / SWAPFILE_CLUSTER;
> > > > > @@ -1182,6 +1182,14 @@ void swapcache_free_cluster(swp_entry_t entry)
> > > > > }
> > > > > #endif /* CONFIG_THP_SWAP */
> > > > >
> > > > > +void swapcache_free(struct page *page, swp_entry_t entry)
> > > > > +{
> > > > > + if (!PageTransHuge(page))
> > > > > + __swapcache_free(entry);
> > > > > + else
> > > > > + __swapcache_free_cluster(entry);
> > > > > +}
> > > >
> > > > I don't think this is cleaner :/
> >
> > Let's see a example add_to_swap. Without it, it looks like that.
> >
> > int add_to_swap(struct page *page)
> > {
> > entry = get_swap_page(page);
> > ..
> > ..
> > fail:
> > if (PageTransHuge(page))
> > swapcache_free_cluster(entry);
> > else
> > swapcache_free(entry);
> > }
> >
> > It doesn't looks good to me because get_swap_page hides
> > where entry allocation is from cluster or slot but when
> > we free the entry allocated, we should be aware of the
> > internal and call right function. :(
>
> This could be nicer indeed. I just don't like the underscore versions
> much, but symmetry with get_swap_page() would be nice.
>
> How about put_swap_page()? :)
Good idea. It's the best one I can do now.
Actually, get_swap_page is awkward to me. Maybe it would be nicer to
rename it with get_swap_[slot|entry] but, I will postpone it if someone
would be on same page with me in future.
>
> That can call the appropriate swapcache_free function then.
Yub.
Thanks for the review!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [v3 0/9] parallelized "struct page" zeroing
From: Pasha Tatashin @ 2017-05-11 20:59 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-kernel, sparclinux, linux-mm, linuxppc-dev, linux-s390,
borntraeger, heiko.carstens, davem
In-Reply-To: <9088ad7e-8b3b-8eba-2fdf-7b0e36e4582e@oracle.com>
We should either keep memset() only for deferred struct pages as what I
have in my patches.
Another option is to add a new function struct_page_clear() which would
default to memset() and to something else on platforms that decide to
optimize it.
On SPARC it would call STBIs, and we would do one membar call after all
"struct pages" are initialized.
I think what I sent out already is cleaner and better solution, because
I am not sure what kind of performance we would see on other chips.
On 05/11/2017 04:47 PM, Pasha Tatashin wrote:
>>>
>>> Have you measured that? I do not think it would be super hard to
>>> measure. I would be quite surprised if this added much if anything at
>>> all as the whole struct page should be in the cache line already. We do
>>> set reference count and other struct members. Almost nobody should be
>>> looking at our page at this time and stealing the cache line. On the
>>> other hand a large memcpy will basically wipe everything away from the
>>> cpu cache. Or am I missing something?
>>>
>
> Here is data for single thread (deferred struct page init is disabled):
>
> Intel CPU E7-8895 v3 @ 2.60GHz 1T memory
> -----------------------------------------
> time to memset "struct pages in memblock: 11.28s
> time to init "struct pag"es: 4.90s
>
> Moving memset into __init_single_page()
> time to init and memset "struct page"es: 8.39s
>
> SPARC M6 @ 3600 MHz 1T memory
> -----------------------------------------
> time to memset "struct pages in memblock: 1.60s
> time to init "struct pag"es: 3.37s
>
> Moving memset into __init_single_page()
> time to init and memset "struct page"es: 12.99s
>
>
> So, moving memset() into __init_single_page() benefits Intel. I am
> actually surprised why memset() is so slow on intel when it is called
> from memblock. But, hurts SPARC, I guess these membars at the end of
> memset() kills the performance.
>
> Also, when looking at these values, remeber that Intel has twice as many
> "struct page" for the same amount of memory.
>
> Pasha
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [v3 0/9] parallelized "struct page" zeroing
From: Pasha Tatashin @ 2017-05-11 20:47 UTC (permalink / raw)
To: Michal Hocko
Cc: linux-kernel, sparclinux, linux-mm, linuxppc-dev, linux-s390,
borntraeger, heiko.carstens, davem
In-Reply-To: <ab667486-54a0-a36e-6797-b5f7b83c10f7@oracle.com>
>>
>> Have you measured that? I do not think it would be super hard to
>> measure. I would be quite surprised if this added much if anything at
>> all as the whole struct page should be in the cache line already. We do
>> set reference count and other struct members. Almost nobody should be
>> looking at our page at this time and stealing the cache line. On the
>> other hand a large memcpy will basically wipe everything away from the
>> cpu cache. Or am I missing something?
>>
Here is data for single thread (deferred struct page init is disabled):
Intel CPU E7-8895 v3 @ 2.60GHz 1T memory
-----------------------------------------
time to memset "struct pages in memblock: 11.28s
time to init "struct pag"es: 4.90s
Moving memset into __init_single_page()
time to init and memset "struct page"es: 8.39s
SPARC M6 @ 3600 MHz 1T memory
-----------------------------------------
time to memset "struct pages in memblock: 1.60s
time to init "struct pag"es: 3.37s
Moving memset into __init_single_page()
time to init and memset "struct page"es: 12.99s
So, moving memset() into __init_single_page() benefits Intel. I am
actually surprised why memset() is so slow on intel when it is called
from memblock. But, hurts SPARC, I guess these membars at the end of
memset() kills the performance.
Also, when looking at these values, remeber that Intel has twice as many
"struct page" for the same amount of memory.
Pasha
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC 04/10] x86/mm: Pass flush_tlb_info to flush_tlb_others() etc
From: Nadav Amit @ 2017-05-11 20:01 UTC (permalink / raw)
To: Andy Lutomirski
Cc: X86 ML, linux-kernel@vger.kernel.org, Borislav Petkov,
Linus Torvalds, Andrew Morton, Mel Gorman, linux-mm@kvack.org,
Rik van Riel, Dave Hansen, Nadav Amit, Michal Hocko, Sasha Levin
In-Reply-To: <51ec06f28360a1cc505649acaf0c9db905824115.1494160201.git.luto@kernel.org>
> On May 7, 2017, at 5:38 AM, Andy Lutomirski <luto@kernel.org> wrote:
>
> @@ -243,15 +237,15 @@ static void flush_tlb_func(void *info)
> return;
> }
>
> - if (f->flush_end == TLB_FLUSH_ALL) {
> + if (f->end == TLB_FLUSH_ALL) {
> local_flush_tlb();
> trace_tlb_flush(TLB_REMOTE_SHOOTDOWN, TLB_FLUSH_ALL);
> } else {
> unsigned long addr;
> unsigned long nr_pages =
> - (f->flush_end - f->flush_start) / PAGE_SIZE;
> - addr = f->flush_start;
> - while (addr < f->flush_end) {
> + (f->end - f->start) / PAGE_SIZE;
> + addr = f->start;
> + while (addr < f->end) {
> __flush_tlb_single(addr);
> addr += PAGE_SIZE;
> }
> @@ -260,33 +254,27 @@ static void flush_tlb_func(void *info)
> }
>
> void native_flush_tlb_others(const struct cpumask *cpumask,
> - struct mm_struct *mm, unsigned long start,
> - unsigned long end)
> + const struct flush_tlb_info *info)
> {
> - struct flush_tlb_info info;
> -
> - info.flush_mm = mm;
> - info.flush_start = start;
> - info.flush_end = end;
> -
> count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
> - if (end == TLB_FLUSH_ALL)
> + if (info->end == TLB_FLUSH_ALL)
> trace_tlb_flush(TLB_REMOTE_SEND_IPI, TLB_FLUSH_ALL);
> else
> trace_tlb_flush(TLB_REMOTE_SEND_IPI,
> - (end - start) >> PAGE_SHIFT);
> + (info->end - info->start) >> PAGE_SHIFT);
I know it is stupid, but since you already change the code, can you make
flush_tlb_func() and native_flush_tlb_others() consistent in the way
they compute the number of pages? (either ‘>> PAGE_SHIFT’ or ‘/ PAGE_SIZE’)?
On a different topic: I do not like or actually understand why TLBSTATE_OK
is defined as 1 and not 0. The very least it would generate a better code.
Thanks,
Nadav
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] mm: per-cgroup memory reclaim stats
From: Roman Gushchin @ 2017-05-11 19:16 UTC (permalink / raw)
To: Johannes Weiner
Cc: Roman Gushchin, Tejun Heo, Li Zefan, Michal Hocko,
Vladimir Davydov, cgroups, linux-doc, linux-kernel, linux-mm
Track the following reclaim counters for every memory cgroup:
PGREFILL, PGSCAN, PGSTEAL, PGACTIVATE, PGDEACTIVATE, PGLAZYFREE and
PGLAZYFREED.
These values are exposed using the memory.stats interface of cgroup v2.
The meaning of each value is the same as for global counters,
available using /proc/vmstat.
Also, for consistency, rename mem_cgroup_count_vm_event() to
count_memcg_event_mm().
Signed-off-by: Roman Gushchin <guro@fb.com>
Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: cgroups@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org
---
Documentation/cgroup-v2.txt | 28 ++++++++++++++++++++++++++
fs/dax.c | 2 +-
fs/ncpfs/mmap.c | 2 +-
include/linux/memcontrol.h | 48 ++++++++++++++++++++++++++++++++++++++++++---
mm/filemap.c | 2 +-
mm/memcontrol.c | 10 ++++++++++
mm/memory.c | 4 ++--
mm/shmem.c | 3 +--
mm/swap.c | 1 +
mm/vmscan.c | 30 +++++++++++++++++++++-------
10 files changed, 113 insertions(+), 17 deletions(-)
diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index e50b95c..5804355 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -918,6 +918,34 @@ PAGE_SIZE multiple when read back.
Number of major page faults incurred
+ pgrefill
+
+ Amount of scanned pages (in an active LRU list)
+
+ pgscan
+
+ Amount of scanned pages (in an inactive LRU list)
+
+ pgsteal
+
+ Amount of reclaimed pages
+
+ pgactivate
+
+ Amount of pages moved to the active LRU list
+
+ pgdeactivate
+
+ Amount of pages moved to the inactive LRU lis
+
+ pglazyfree
+
+ Amount of pages postponed to be freed under memory pressure
+
+ pglazyfreed
+
+ Amount of reclaimed lazyfree pages
+
memory.swap.current
A read-only single value file which exists on non-root
diff --git a/fs/dax.c b/fs/dax.c
index 66d7906..9aac521d 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1230,7 +1230,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
case IOMAP_MAPPED:
if (iomap.flags & IOMAP_F_NEW) {
count_vm_event(PGMAJFAULT);
- mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
+ count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
major = VM_FAULT_MAJOR;
}
error = dax_insert_mapping(mapping, iomap.bdev, iomap.dax_dev,
diff --git a/fs/ncpfs/mmap.c b/fs/ncpfs/mmap.c
index 0c3905e..6719c0b 100644
--- a/fs/ncpfs/mmap.c
+++ b/fs/ncpfs/mmap.c
@@ -89,7 +89,7 @@ static int ncp_file_mmap_fault(struct vm_fault *vmf)
* -- nyc
*/
count_vm_event(PGMAJFAULT);
- mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
+ count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
return VM_FAULT_MAJOR;
}
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 899949b..b2a5b1c 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -357,6 +357,17 @@ static inline unsigned short mem_cgroup_id(struct mem_cgroup *memcg)
}
struct mem_cgroup *mem_cgroup_from_id(unsigned short id);
+static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
+{
+ struct mem_cgroup_per_node *mz;
+
+ if (mem_cgroup_disabled())
+ return NULL;
+
+ mz = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
+ return mz->memcg;
+}
+
/**
* parent_mem_cgroup - find the accounting parent of a memcg
* @memcg: memcg whose parent to find
@@ -546,8 +557,23 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order,
gfp_t gfp_mask,
unsigned long *total_scanned);
-static inline void mem_cgroup_count_vm_event(struct mm_struct *mm,
- enum vm_event_item idx)
+static inline void count_memcg_events(struct mem_cgroup *memcg,
+ enum vm_event_item idx,
+ unsigned long count)
+{
+ if (!mem_cgroup_disabled())
+ this_cpu_add(memcg->stat->events[idx], count);
+}
+
+static inline void count_memcg_page_event(struct page *page,
+ enum memcg_stat_item idx)
+{
+ if (page->mem_cgroup)
+ count_memcg_events(page->mem_cgroup, idx, 1);
+}
+
+static inline void count_memcg_event_mm(struct mm_struct *mm,
+ enum vm_event_item idx)
{
struct mem_cgroup *memcg;
@@ -675,6 +701,11 @@ static inline struct mem_cgroup *mem_cgroup_from_id(unsigned short id)
return NULL;
}
+static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
+{
+ return NULL;
+}
+
static inline bool mem_cgroup_online(struct mem_cgroup *memcg)
{
return true;
@@ -789,8 +820,19 @@ static inline void mem_cgroup_split_huge_fixup(struct page *head)
{
}
+static inline void count_memcg_events(struct mem_cgroup *memcg,
+ enum vm_event_item idx,
+ unsigned long count)
+{
+}
+
+static inline void count_memcg_page_event(struct page *page,
+ enum memcg_stat_item idx)
+{
+}
+
static inline
-void mem_cgroup_count_vm_event(struct mm_struct *mm, enum vm_event_item idx)
+void count_memcg_event_mm(struct mm_struct *mm, enum vm_event_item idx)
{
}
#endif /* CONFIG_MEMCG */
diff --git a/mm/filemap.c b/mm/filemap.c
index b7b973b..d640613 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2226,7 +2226,7 @@ int filemap_fault(struct vm_fault *vmf)
/* No page in the page cache at all */
do_sync_mmap_readahead(vmf->vma, ra, file, offset);
count_vm_event(PGMAJFAULT);
- mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
+ count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
ret = VM_FAULT_MAJOR;
retry_find:
page = find_get_page(mapping, offset);
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index ff73899..0cfa0aa 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5231,6 +5231,16 @@ static int memory_stat_show(struct seq_file *m, void *v)
seq_printf(m, "pgfault %lu\n", events[PGFAULT]);
seq_printf(m, "pgmajfault %lu\n", events[PGMAJFAULT]);
+ seq_printf(m, "pgrefill %lu\n", events[PGREFILL]);
+ seq_printf(m, "pgscan %lu\n", events[PGSCAN_KSWAPD] +
+ events[PGSCAN_DIRECT]);
+ seq_printf(m, "pgsteal %lu\n", events[PGSTEAL_KSWAPD] +
+ events[PGSTEAL_DIRECT]);
+ seq_printf(m, "pgactivate %lu\n", events[PGACTIVATE]);
+ seq_printf(m, "pgdeactivate %lu\n", events[PGDEACTIVATE]);
+ seq_printf(m, "pglazyfree %lu\n", events[PGLAZYFREE]);
+ seq_printf(m, "pglazyfreed %lu\n", events[PGLAZYFREED]);
+
seq_printf(m, "workingset_refault %lu\n",
stat[WORKINGSET_REFAULT]);
seq_printf(m, "workingset_activate %lu\n",
diff --git a/mm/memory.c b/mm/memory.c
index 6ff5d72..5aa1348 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2719,7 +2719,7 @@ int do_swap_page(struct vm_fault *vmf)
/* Had to read the page from swap area: Major fault */
ret = VM_FAULT_MAJOR;
count_vm_event(PGMAJFAULT);
- mem_cgroup_count_vm_event(vma->vm_mm, PGMAJFAULT);
+ count_memcg_event_mm(vma->vm_mm, PGMAJFAULT);
} else if (PageHWPoison(page)) {
/*
* hwpoisoned dirty swapcache pages are kept for killing
@@ -3855,7 +3855,7 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
__set_current_state(TASK_RUNNING);
count_vm_event(PGFAULT);
- mem_cgroup_count_vm_event(vma->vm_mm, PGFAULT);
+ count_memcg_event_mm(vma->vm_mm, PGFAULT);
/* do counter updates before entering really critical section. */
check_sync_rss_stat(current);
diff --git a/mm/shmem.c b/mm/shmem.c
index e67d6ba..8cf16fb 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1645,8 +1645,7 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
if (fault_type) {
*fault_type |= VM_FAULT_MAJOR;
count_vm_event(PGMAJFAULT);
- mem_cgroup_count_vm_event(charge_mm,
- PGMAJFAULT);
+ count_memcg_event_mm(charge_mm, PGMAJFAULT);
}
/* Here we actually start the io */
page = shmem_swapin(swap, gfp, info, index);
diff --git a/mm/swap.c b/mm/swap.c
index 98d08b4..4f44dbd 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -591,6 +591,7 @@ static void lru_lazyfree_fn(struct page *page, struct lruvec *lruvec,
add_page_to_lru_list(page, lruvec, LRU_INACTIVE_FILE);
__count_vm_events(PGLAZYFREE, hpage_nr_pages(page));
+ count_memcg_page_event(page, PGLAZYFREE);
update_page_reclaim_stat(lruvec, 1, 0);
}
}
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 5ebf468..76e98b5 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1266,6 +1266,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
}
count_vm_event(PGLAZYFREED);
+ count_memcg_page_event(page, PGLAZYFREED);
} else if (!mapping || !__remove_mapping(mapping, page, true))
goto keep_locked;
/*
@@ -1295,6 +1296,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
if (!PageMlocked(page)) {
SetPageActive(page);
pgactivate++;
+ count_memcg_page_event(page, PGACTIVATE);
}
keep_locked:
unlock_page(page);
@@ -1725,11 +1727,16 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
__mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, nr_taken);
reclaim_stat->recent_scanned[file] += nr_taken;
- if (global_reclaim(sc)) {
- if (current_is_kswapd())
+ if (current_is_kswapd()) {
+ if (global_reclaim(sc))
__count_vm_events(PGSCAN_KSWAPD, nr_scanned);
- else
+ count_memcg_events(lruvec_memcg(lruvec), PGSCAN_KSWAPD,
+ nr_scanned);
+ } else {
+ if (global_reclaim(sc))
__count_vm_events(PGSCAN_DIRECT, nr_scanned);
+ count_memcg_events(lruvec_memcg(lruvec), PGSCAN_DIRECT,
+ nr_scanned);
}
spin_unlock_irq(&pgdat->lru_lock);
@@ -1741,11 +1748,16 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec,
spin_lock_irq(&pgdat->lru_lock);
- if (global_reclaim(sc)) {
- if (current_is_kswapd())
+ if (current_is_kswapd()) {
+ if (global_reclaim(sc))
__count_vm_events(PGSTEAL_KSWAPD, nr_reclaimed);
- else
+ count_memcg_events(lruvec_memcg(lruvec), PGSTEAL_KSWAPD,
+ nr_reclaimed);
+ } else {
+ if (global_reclaim(sc))
__count_vm_events(PGSTEAL_DIRECT, nr_reclaimed);
+ count_memcg_events(lruvec_memcg(lruvec), PGSTEAL_DIRECT,
+ nr_reclaimed);
}
putback_inactive_pages(lruvec, &page_list);
@@ -1890,8 +1902,11 @@ static unsigned move_active_pages_to_lru(struct lruvec *lruvec,
}
}
- if (!is_active_lru(lru))
+ if (!is_active_lru(lru)) {
__count_vm_events(PGDEACTIVATE, nr_moved);
+ count_memcg_events(lruvec_memcg(lruvec), PGDEACTIVATE,
+ nr_moved);
+ }
return nr_moved;
}
@@ -1929,6 +1944,7 @@ static void shrink_active_list(unsigned long nr_to_scan,
reclaim_stat->recent_scanned[file] += nr_taken;
__count_vm_events(PGREFILL, nr_scanned);
+ count_memcg_events(lruvec_memcg(lruvec), PGREFILL, nr_scanned);
spin_unlock_irq(&pgdat->lru_lock);
--
2.7.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [RFC 01/10] x86/mm: Reimplement flush_tlb_page() using flush_tlb_mm_range()
From: Borislav Petkov @ 2017-05-11 17:41 UTC (permalink / raw)
To: Andy Lutomirski
Cc: X86 ML, linux-kernel@vger.kernel.org, Linus Torvalds,
Andrew Morton, Mel Gorman, linux-mm@kvack.org, Rik van Riel,
Dave Hansen, Nadav Amit, Michal Hocko
In-Reply-To: <dbe03b624fb5e785d33ca71c98f113f05d7b12df.1494160201.git.luto@kernel.org>
On Sun, May 07, 2017 at 05:38:30AM -0700, Andy Lutomirski wrote:
> flush_tlb_page() was very similar to flush_tlb_mm_range() except that
> it had a couple of issues:
>
> - It was missing an smp_mb() in the case where
> current->active_mm != mm. (This is a longstanding bug reported by
> Nadav Amit.)
>
> - It was missing tracepoints and vm counter updates.
>
> The only reason that I can see for keeping it at as a separate
> function is that it could avoid a few branches that
> flush_tlb_mm_range() needs to decide to flush just one page. This
> hardly seems worthwhile. If we decide we want to get rid of those
> branches again, a better way would be to introduce an
> __flush_tlb_mm_range() helper and make both flush_tlb_page() and
> flush_tlb_mm_range() use it.
>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Nadav Amit <namit@vmware.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
> arch/x86/include/asm/tlbflush.h | 6 +++++-
> arch/x86/mm/tlb.c | 27 ---------------------------
> 2 files changed, 5 insertions(+), 28 deletions(-)
>
> diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
> index 6ed9ea469b48..5ed64cdaf536 100644
> --- a/arch/x86/include/asm/tlbflush.h
> +++ b/arch/x86/include/asm/tlbflush.h
> @@ -307,11 +307,15 @@ static inline void flush_tlb_kernel_range(unsigned long start,
> flush_tlb_mm_range(vma->vm_mm, start, end, vma->vm_flags)
>
> extern void flush_tlb_all(void);
> -extern void flush_tlb_page(struct vm_area_struct *, unsigned long);
> extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
> unsigned long end, unsigned long vmflag);
> extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
>
> +static inline void flush_tlb_page(struct vm_area_struct *vma, unsigned long a)
> +{
> + flush_tlb_mm_range(vma->vm_mm, a, a + PAGE_SIZE, 0);
VM_NONE);
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix ImendA?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG NA 1/4 rnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* AW: Kernel problem
From: Frank Vosberg @ 2017-05-11 17:30 UTC (permalink / raw)
To: Randy Dunlap, linux-mm@kvack.org
In-Reply-To: <bbde3fc7-fa8c-7872-1099-44a3c293ffba@infradead.org>
It is just a new message, the same kernel is running on 2 other systems with the same config (Hard and soft config )fine.
I can not see any hardware problems in the HP ILO files.
Can it be a hardware problem may be too many mem errors, which are not showing up in the HP IOL ?
-----Ursprüngliche Nachricht-----
Von: Randy Dunlap [mailto:rdunlap@infradead.org]
Gesendet: Donnerstag, 11. Mai 2017 18:57
An: Frank Vosberg <frank.vosberg@sscs.com>; linux-mm@kvack.org
Betreff: Re: Kernel problem
On 05/11/17 08:17, Frank Vosberg wrote:
> Hi all,
>
>
>
> I got the following message where I found this mail address, so can you let me what is wrong with the system ?
Try to make it readable (breaking the lines)...
>> kernel-default-3.0.101
Is this a new kernel for you? New installation or software upgrade?
or is it just a new message?
What distro kernel is this? For a kernel that old, you will probably need to contact them.
I'll let someone else comment on the actual warning message:
Creating hierarchies with use_hierarchy==0 (flat hierarchy) is considered deprecated. If you believe that your setup is correct, we kindly ask you to contact linux-mm@kvack.org and let us know
May 6 18:04:03 musxaura006 kernel: [ 142.119654] ------------[ cut here ]------------ May 6 18:04:03 musxaura006 kernel: [ 142.119670] WARNING: at /usr/src/packages/BUILD/kernel-default-3.0.101/linux-3.0/mm/memcontrol.c:5028 mem_cgroup_create+0x394/0x4a0() May 6 18:04:03 musxaura006 kernel: [ 142.119672] Hardware name: ProLiant DL580 G7 May 6 18:04:03 musxaura006 kernel: [ 142.119674] Creating hierarchies with use_hierarchy==0 (flat hierarchy) is considered deprecated. If you believe that your setup is correct, we kindly ask you to contact linux-mm@kvack.org and let us know May 6 18:04:03 musxaura006 kernel: [ 142.119677] Modules linked in: mvfs(EX) nfsd autofs4 binfmt_misc ipmi_devintf edd rpcsec_gss_krb5 nfs lockd fscache auth_rpcgss nfs_acl sunrpc cpufreq_conservative cpufreq_userspace cpufreq_powersave pcc_cpufreq mperf nls_iso8859_1 nls_cp437 vfat fat loop dm_mod hpwdt netxen_nic hpilo ipv6_lib sg shpchp iTCO_wdt sr_mod i7core_edac iTCO_vendor_support edac_core
> cdrom ipmi_si pci_hotplug serio_raw acpi_power_meter pcspkr
> ipmi_msghandler rtc_cmos button container ext3 jbd mbcache radeon ttm
> drm_kms_helper drm i2c_algo_bit i2c_core uhci_hcd ehci_hcd usbcore
> usb_common thermal processor thermal_sys hwmon scsi_dh_alua
> scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh ata_generic ata_piix
> libata hpsa cciss scsi_mod
May 6 18:04:03 musxaura006 kernel: [ 142.119726] Supported: Yes, External
May 6 18:04:03 musxaura006 kernel: [ 142.119729] Pid: 8772, comm: java Tainted: G E X 3.0.101-84-default #1
May 6 18:04:03 musxaura006 kernel: [ 142.119731] Call Trace:
May 6 18:04:03 musxaura006 kernel: [ 142.119746] [<ffffffff81004b95>] dump_trace+0x75/0x300 May 6 18:04:03 musxaura006 kernel: [ 142.119753] [<ffffffff81466c03>] dump_stack+0x69/0x6f May 6 18:04:03 musxaura006 kernel: [ 142.119761] [<ffffffff81062157>] warn_slowpath_common+0x87/0xe0 May 6 18:04:03 musxaura006 kernel: [ 142.119765] [<ffffffff81062265>] warn_slowpath_fmt+0x45/0x60 May 6 18:04:03 musxaura006 kernel: [ 142.119769] [<ffffffff81450ee4>] mem_cgroup_create+0x394/0x4a0 May 6 18:04:03 musxaura006 kernel: [ 142.119777] [<ffffffff810b7b11>] cgroup_create+0x191/0x530 May 6 18:04:03 musxaura006 kernel: [ 142.119781] [<ffffffff810b7ec4>] cgroup_mkdir+0x14/0x20 May 6 18:04:03 musxaura006 kernel: [ 142.119789] [<ffffffff8116c7fd>] vfs_mkdir+0xad/0x130 May 6 18:04:03 musxaura006 kernel: [ 142.119794] [<ffffffff8116f755>] sys_mkdirat+0x165/0x180 May 6 18:04:03 musxaura006 kernel: [ 142.119801] [<ffffffff81471df2>] system_call_fastpath+0x16/0x1b May 6 18:04:03 musxaura006 kernel: [ 142.119807] [<00007f474b1c9967>] 0x7f474b1c9966 May 6 18:04:03 musxaura006 kernel: [ 142.119809] ---[ end trace 8db4a943075b8e6e ]---
--
~Randy
CONFIDENTIALITY NOTE: The information contained in this message may be privileged, confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or any employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. SSCS, Inc. 800-833-8223
CONFIDENTIALITY NOTE: The information contained in this message may be privileged, confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or any employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. SSCS, Inc. 800-833-8223
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Kernel problem
From: Randy Dunlap @ 2017-05-11 16:57 UTC (permalink / raw)
To: Frank Vosberg, linux-mm@kvack.org
In-Reply-To: <DM5PR15MB13399384EF35EF4451D31C2183ED0@DM5PR15MB1339.namprd15.prod.outlook.com>
On 05/11/17 08:17, Frank Vosberg wrote:
> Hi all,
>
>
>
> I got the following message where I found this mail address, so can you let me what is wrong with the system ?
Try to make it readable (breaking the lines)...
>> kernel-default-3.0.101
Is this a new kernel for you? New installation or software upgrade?
or is it just a new message?
What distro kernel is this? For a kernel that old, you will probably
need to contact them.
I'll let someone else comment on the actual warning message:
Creating hierarchies with use_hierarchy==0 (flat hierarchy) is considered deprecated. If you believe that your setup is correct, we kindly ask you to contact linux-mm@kvack.org and let us know
May 6 18:04:03 musxaura006 kernel: [ 142.119654] ------------[ cut here ]------------
May 6 18:04:03 musxaura006 kernel: [ 142.119670] WARNING: at /usr/src/packages/BUILD/kernel-default-3.0.101/linux-3.0/mm/memcontrol.c:5028 mem_cgroup_create+0x394/0x4a0()
May 6 18:04:03 musxaura006 kernel: [ 142.119672] Hardware name: ProLiant DL580 G7
May 6 18:04:03 musxaura006 kernel: [ 142.119674] Creating hierarchies with use_hierarchy==0 (flat hierarchy) is considered deprecated. If you believe that your setup is correct, we kindly ask you to contact linux-mm@kvack.org and let us know
May 6 18:04:03 musxaura006 kernel: [ 142.119677] Modules linked in: mvfs(EX) nfsd autofs4 binfmt_misc ipmi_devintf edd rpcsec_gss_krb5 nfs lockd fscache auth_rpcgss nfs_acl sunrpc cpufreq_conservative cpufreq_userspace cpufreq_powersave pcc_cpufreq mperf nls_iso8859_1 nls_cp437 vfat fat loop dm_mod hpwdt netxen_nic hpilo ipv6_lib sg shpchp iTCO_wdt sr_mod i7core_edac iTCO_vendor_support edac_core
> cdrom ipmi_si pci_hotplug serio_raw acpi_power_meter pcspkr ipmi_msghandler rtc_cmos button container ext3 jbd mbcache radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core uhci_hcd ehci_hcd usbcore usb_common thermal processor thermal_sys hwmon scsi_dh_alua scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata hpsa cciss scsi_mod
May 6 18:04:03 musxaura006 kernel: [ 142.119726] Supported: Yes, External
May 6 18:04:03 musxaura006 kernel: [ 142.119729] Pid: 8772, comm: java Tainted: G E X 3.0.101-84-default #1
May 6 18:04:03 musxaura006 kernel: [ 142.119731] Call Trace:
May 6 18:04:03 musxaura006 kernel: [ 142.119746] [<ffffffff81004b95>] dump_trace+0x75/0x300 May 6 18:04:03 musxaura006 kernel: [ 142.119753] [<ffffffff81466c03>] dump_stack+0x69/0x6f May 6 18:04:03 musxaura006 kernel: [ 142.119761] [<ffffffff81062157>] warn_slowpath_common+0x87/0xe0
May 6 18:04:03 musxaura006 kernel: [ 142.119765] [<ffffffff81062265>] warn_slowpath_fmt+0x45/0x60
May 6 18:04:03 musxaura006 kernel: [ 142.119769] [<ffffffff81450ee4>] mem_cgroup_create+0x394/0x4a0
May 6 18:04:03 musxaura006 kernel: [ 142.119777] [<ffffffff810b7b11>] cgroup_create+0x191/0x530
May 6 18:04:03 musxaura006 kernel: [ 142.119781] [<ffffffff810b7ec4>] cgroup_mkdir+0x14/0x20
May 6 18:04:03 musxaura006 kernel: [ 142.119789] [<ffffffff8116c7fd>] vfs_mkdir+0xad/0x130 May 6 18:04:03 musxaura006 kernel: [ 142.119794] [<ffffffff8116f755>] sys_mkdirat+0x165/0x180
May 6 18:04:03 musxaura006 kernel: [ 142.119801] [<ffffffff81471df2>] system_call_fastpath+0x16/0x1b
May 6 18:04:03 musxaura006 kernel: [ 142.119807] [<00007f474b1c9967>] 0x7f474b1c9966
May 6 18:04:03 musxaura006 kernel: [ 142.119809] ---[ end trace 8db4a943075b8e6e ]---
--
~Randy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration
From: Christoph Lameter @ 2017-05-11 15:37 UTC (permalink / raw)
To: Luiz Capitulino
Cc: Marcelo Tosatti, linux-kernel, linux-mm, Rik van Riel,
Linux RT Users, cmetcalf
In-Reply-To: <20170502131527.7532fc2e@redhat.com>
On Tue, 2 May 2017, Luiz Capitulino wrote:
> Ah, OK. Got this now. I'll give this patch a try. But I think we want
> to hear from Christoph (who worked on reducing the vmstat interruptions
> in the past).
A bit confused by this one. The vmstat worker is already disabled if there
are no updates. Also the patches by Chris Metcalf on data plane mode add a
prctl to quiet the vmstat workers.
Why do we need more than this?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch 3/3] MM: allow per-cpu vmstat_worker configuration
From: Marcelo Tosatti @ 2017-05-11 15:33 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-kernel, linux-mm, Luiz Capitulino, Linux RT Users
In-Reply-To: <1494430466.29205.17.camel@redhat.com>
On Wed, May 10, 2017 at 11:34:26AM -0400, Rik van Riel wrote:
> On Wed, 2017-05-03 at 15:40 -0300, Marcelo Tosatti wrote:
> > Following the reasoning on the last patch in the series,
> > this patch allows configuration of the per-CPU vmstat worker:
> > it allows the user to disable the per-CPU vmstat worker.
> >
> > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>
> Is there ever a case where you would want to configure
> this separately from the vmstat_threshold parameter?
>
> What use cases are you trying to address?
If you have a case where the performance decrease due to lack of vmstat
collection aggretation (vmstat_threshold=1) is significant, so you
increase vmstat_threshold on these CPUs to, say, 10 (and is willing to
accept the cost of outdated vmstatistics by 10).
This is the case that i imagined when separating the options in two
(with the idea to have policy in userspace, not in the kernel).
Do you think such case is not realistic? (Or that there are other
problems by having vmstat_threshold > 1 and vmstat_worker=0).
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Kernel problem
From: Frank Vosberg @ 2017-05-11 15:17 UTC (permalink / raw)
To: linux-mm@kvack.org
[-- Attachment #1: Type: text/plain, Size: 3911 bytes --]
Hi all,
I got the following message where I found this mail address, so can you let me what is wrong with the system ?
May 6 18:04:03 musxaura006 kernel: [ 142.119654] ------------[ cut here ]------------ May 6 18:04:03 musxaura006 kernel: [ 142.119670] WARNING: at /usr/src/packages/BUILD/kernel-default-3.0.101/linux-3.0/mm/memcontrol.c:5028 mem_cgroup_create+0x394/0x4a0() May 6 18:04:03 musxaura006 kernel: [ 142.119672] Hardware name: ProLiant DL580 G7 May 6 18:04:03 musxaura006 kernel: [ 142.119674] Creating hierarchies with use_hierarchy==0 (flat hierarchy) is considered deprecated. If you believe that your setup is correct, we kindly ask you to contact linux-mm@kvack.org and let us know May 6 18:04:03 musxaura006 kernel: [ 142.119677] Modules linked in: mvfs(EX) nfsd autofs4 binfmt_misc ipmi_devintf edd rpcsec_gss_krb5 nfs lockd fscache auth_rpcgss nfs_acl sunrpc cpufreq_conservative cpufreq_userspace cpufreq_powersave pcc_cpufreq mperf nls_iso8859_1 nls_cp437 vfat fat loop dm_mod hpwdt netxen_nic hpilo ipv6_lib sg shpchp iTCO_wdt sr_mod i7core_edac iTCO_vendor_support edac_core cdrom ipmi_si pci_hotplug serio_raw acpi_power_meter pcspkr ipmi_msghandler rtc_cmos button container ext3 jbd mbcache radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core uhci_hcd ehci_hcd usbcore usb_common thermal processor thermal_sys hwmon scsi_dh_alua scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata hpsa cciss scsi_mod May 6 18:04:03 musxaura006 kernel: [ 142.119726] Supported: Yes, External
May 6 18:04:03 musxaura006 kernel: [ 142.119729] Pid: 8772, comm: java Tainted: G E X 3.0.101-84-default #1
May 6 18:04:03 musxaura006 kernel: [ 142.119731] Call Trace:
May 6 18:04:03 musxaura006 kernel: [ 142.119746] [<ffffffff81004b95>] dump_trace+0x75/0x300 May 6 18:04:03 musxaura006 kernel: [ 142.119753] [<ffffffff81466c03>] dump_stack+0x69/0x6f May 6 18:04:03 musxaura006 kernel: [ 142.119761] [<ffffffff81062157>] warn_slowpath_common+0x87/0xe0 May 6 18:04:03 musxaura006 kernel: [ 142.119765] [<ffffffff81062265>] warn_slowpath_fmt+0x45/0x60 May 6 18:04:03 musxaura006 kernel: [ 142.119769] [<ffffffff81450ee4>] mem_cgroup_create+0x394/0x4a0 May 6 18:04:03 musxaura006 kernel: [ 142.119777] [<ffffffff810b7b11>] cgroup_create+0x191/0x530 May 6 18:04:03 musxaura006 kernel: [ 142.119781] [<ffffffff810b7ec4>] cgroup_mkdir+0x14/0x20 May 6 18:04:03 musxaura006 kernel: [ 142.119789] [<ffffffff8116c7fd>] vfs_mkdir+0xad/0x130 May 6 18:04:03 musxaura006 kernel: [ 142.119794] [<ffffffff8116f755>] sys_mkdirat+0x165/0x180 May 6 18:04:03 musxaura006 kernel: [ 142.119801] [<ffffffff81471df2>] system_call_fastpath+0x16/0x1b May 6 18:04:03 musxaura006 kernel: [ 142.119807] [<00007f474b1c9967>] 0x7f474b1c9966 May 6 18:04:03 musxaura006 kernel: [ 142.119809] ---[ end trace 8db4a943075b8e6e ]---
Mit freundlichen Grüssen / Kind Regards
Frank Vosberg
Service Delivery Manager DACH
Solid Systems CAD Services GmbH
Nobelstrasse 1a
DE - 85757 Karlsfeld
+49 176 15858700 Mobile
+1.877.904.7727 Global Call Center
frank.vosberg@sscs.com<mailto:frank.vosberg@sscs.com>
www.sscs.com<http://www.sscs.com/>
Geschäftsführer: William H. Olund, Gahlen W. Carpenter, Anja Harrell
Registergericht München, HRB 218212
CONFIDENTIALITY NOTE: The information contained in this message may be privileged, confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or any employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. SSCS, Inc. 800-833-8223
[-- Attachment #2: Type: text/html, Size: 9602 bytes --]
^ permalink raw reply
* Re: [v3 0/9] parallelized "struct page" zeroing
From: David Miller @ 2017-05-11 14:35 UTC (permalink / raw)
To: mhocko
Cc: pasha.tatashin, linux-kernel, sparclinux, linux-mm, linuxppc-dev,
linux-s390, borntraeger, heiko.carstens
In-Reply-To: <20170511080537.GE26782@dhcp22.suse.cz>
From: Michal Hocko <mhocko@kernel.org>
Date: Thu, 11 May 2017 10:05:38 +0200
> Anyway, do you agree that doing the struct page initialization along
> with other writes to it shouldn't add a measurable overhead comparing
> to pre-zeroing of larger block of struct pages? We already have an
> exclusive cache line and doing one 64B write along with few other stores
> should be basically the same.
Yes, it should be reasonably cheap.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: Silence first allocation with CONFIG_ARM64_MODULE_PLTS=y
From: Catalin Marinas @ 2017-05-11 13:53 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-kernel, Florian Fainelli, Ard Biesheuvel, Russell King,
open list, open list:MEMORY MANAGEMENT, Michal Hocko, zijun_hu,
angus, Andrey Ryabinin, Andrew Morton, Chris Wilson,
Kirill A. Shutemov
In-Reply-To: <20170510115511.GB15307@arm.com>
On Wed, May 10, 2017 at 12:55:12PM +0100, Will Deacon wrote:
> On Wed, May 10, 2017 at 09:38:03AM +0100, Catalin Marinas wrote:
> > On Mon, May 08, 2017 at 11:07:24AM +0100, Will Deacon wrote:
> > > On Fri, May 05, 2017 at 02:07:28PM -0700, Florian Fainelli wrote:
> > > > On 05/03/2017 04:18 AM, Will Deacon wrote:
> > > > > On Thu, Apr 27, 2017 at 11:19:02AM -0700, Florian Fainelli wrote:
> > > > >> When CONFIG_ARM64_MODULE_PLTS is enabled, the first allocation using the
> > > > >> module space fails, because the module is too big, and then the module
> > > > >> allocation is attempted from vmalloc space. Silence the first allocation
> > > > >> failure in that case by setting __GFP_NOWARN.
> > > > >>
> > > > >> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > > >> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> > > > >> ---
> > > > >> arch/arm64/kernel/module.c | 7 ++++++-
> > > > >> 1 file changed, 6 insertions(+), 1 deletion(-)
> > > > >
> > > > > I'm not sure what the merge plan is for these, but the arm64 bit here
> > > > > looks fine to me:
> > > > >
> > > > > Acked-by: Will Deacon <will.deacon@arm.com>
> > > >
> > > > Thanks, not sure either, would you or Catalin want to pick this series?
> > >
> > > We'd need an Ack from Russell on the arch/arm/ part before we could take
> > > this series.
> >
> > The first patch touches mm/vmalloc.c, so we could also merge the series
> > via akpm's tree. Andrew, do you have any preference?
>
> Michal Hocko acked that one, so I think we can take the whole series via
> arm64.
OK. I'll send the patches for -rc1.
Thanks.
--
Catalin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH -mm -v10 1/3] mm, THP, swap: Delay splitting THP during swap out
From: Johannes Weiner @ 2017-05-11 10:40 UTC (permalink / raw)
To: Minchan Kim
Cc: Huang, Ying, Andrew Morton, linux-mm, linux-kernel,
Andrea Arcangeli, Ebru Akagunduz, Michal Hocko, Tejun Heo,
Hugh Dickins, Shaohua Li, Rik van Riel, cgroups
In-Reply-To: <20170511012213.GA27659@bbox>
On Thu, May 11, 2017 at 10:22:13AM +0900, Minchan Kim wrote:
> On Thu, May 11, 2017 at 08:25:56AM +0900, Minchan Kim wrote:
> > On Wed, May 10, 2017 at 09:56:54AM -0400, Johannes Weiner wrote:
> > > Hi Michan,
> > >
> > > On Tue, May 02, 2017 at 08:53:32AM +0900, Minchan Kim wrote:
> > > > @@ -1144,7 +1144,7 @@ void swap_free(swp_entry_t entry)
> > > > /*
> > > > * Called after dropping swapcache to decrease refcnt to swap entries.
> > > > */
> > > > -void swapcache_free(swp_entry_t entry)
> > > > +void __swapcache_free(swp_entry_t entry)
> > > > {
> > > > struct swap_info_struct *p;
> > > >
> > > > @@ -1156,7 +1156,7 @@ void swapcache_free(swp_entry_t entry)
> > > > }
> > > >
> > > > #ifdef CONFIG_THP_SWAP
> > > > -void swapcache_free_cluster(swp_entry_t entry)
> > > > +void __swapcache_free_cluster(swp_entry_t entry)
> > > > {
> > > > unsigned long offset = swp_offset(entry);
> > > > unsigned long idx = offset / SWAPFILE_CLUSTER;
> > > > @@ -1182,6 +1182,14 @@ void swapcache_free_cluster(swp_entry_t entry)
> > > > }
> > > > #endif /* CONFIG_THP_SWAP */
> > > >
> > > > +void swapcache_free(struct page *page, swp_entry_t entry)
> > > > +{
> > > > + if (!PageTransHuge(page))
> > > > + __swapcache_free(entry);
> > > > + else
> > > > + __swapcache_free_cluster(entry);
> > > > +}
> > >
> > > I don't think this is cleaner :/
>
> Let's see a example add_to_swap. Without it, it looks like that.
>
> int add_to_swap(struct page *page)
> {
> entry = get_swap_page(page);
> ..
> ..
> fail:
> if (PageTransHuge(page))
> swapcache_free_cluster(entry);
> else
> swapcache_free(entry);
> }
>
> It doesn't looks good to me because get_swap_page hides
> where entry allocation is from cluster or slot but when
> we free the entry allocated, we should be aware of the
> internal and call right function. :(
This could be nicer indeed. I just don't like the underscore versions
much, but symmetry with get_swap_page() would be nice.
How about put_swap_page()? :)
That can call the appropriate swapcache_free function then.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v2] mm: vmscan: scan until it founds eligible pages
From: Johannes Weiner @ 2017-05-11 10:35 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, linux-kernel, linux-mm, Mel Gorman, Michal Hocko,
kernel-team
In-Reply-To: <1494457232-27401-1-git-send-email-minchan@kernel.org>
On Thu, May 11, 2017 at 08:00:32AM +0900, Minchan Kim wrote:
> Although there are a ton of free swap and anonymous LRU page
> in elgible zones, OOM happened.
>
> balloon invoked oom-killer: gfp_mask=0x17080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), nodemask=(null), order=0, oom_score_adj=0
> CPU: 7 PID: 1138 Comm: balloon Not tainted 4.11.0-rc6-mm1-zram-00289-ge228d67e9677-dirty #17
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
> Call Trace:
> dump_stack+0x65/0x87
> dump_header.isra.19+0x8f/0x20f
> ? preempt_count_add+0x9e/0xb0
> ? _raw_spin_unlock_irqrestore+0x24/0x40
> oom_kill_process+0x21d/0x3f0
> ? has_capability_noaudit+0x17/0x20
> out_of_memory+0xd8/0x390
> __alloc_pages_slowpath+0xbc1/0xc50
> ? anon_vma_interval_tree_insert+0x84/0x90
> __alloc_pages_nodemask+0x1a5/0x1c0
> pte_alloc_one+0x20/0x50
> __pte_alloc+0x1e/0x110
> __handle_mm_fault+0x919/0x960
> handle_mm_fault+0x77/0x120
> __do_page_fault+0x27a/0x550
> trace_do_page_fault+0x43/0x150
> do_async_page_fault+0x2c/0x90
> async_page_fault+0x28/0x30
> RIP: 0033:0x7fc4636bacb8
> RSP: 002b:00007fff97c9c4c0 EFLAGS: 00010202
> RAX: 00007fc3e818d000 RBX: 00007fc4639f8760 RCX: 00007fc46372e9ca
> RDX: 0000000000101002 RSI: 0000000000101000 RDI: 0000000000000000
> RBP: 0000000000100010 R08: 00000000ffffffff R09: 0000000000000000
> R10: 0000000000000022 R11: 00000000000a3901 R12: 00007fc3e818d010
> R13: 0000000000101000 R14: 00007fc4639f87b8 R15: 00007fc4639f87b8
> Mem-Info:
> active_anon:424716 inactive_anon:65314 isolated_anon:0
> active_file:52 inactive_file:46 isolated_file:0
> unevictable:0 dirty:27 writeback:0 unstable:0
> slab_reclaimable:3967 slab_unreclaimable:4125
> mapped:133 shmem:43 pagetables:1674 bounce:0
> free:4637 free_pcp:225 free_cma:0
> Node 0 active_anon:1698864kB inactive_anon:261256kB active_file:208kB inactive_file:184kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:532kB dirty:108kB writeback:0kB shmem:172kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
> DMA free:7316kB min:32kB low:44kB high:56kB active_anon:8064kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB slab_reclaimable:464kB slab_unreclaimable:40kB kernel_stack:0kB pagetables:24kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> lowmem_reserve[]: 0 992 992 1952
> DMA32 free:9088kB min:2048kB low:3064kB high:4080kB active_anon:952176kB inactive_anon:0kB active_file:36kB inactive_file:0kB unevictable:0kB writepending:88kB present:1032192kB managed:1019388kB mlocked:0kB slab_reclaimable:13532kB slab_unreclaimable:16460kB kernel_stack:3552kB pagetables:6672kB bounce:0kB free_pcp:56kB local_pcp:24kB free_cma:0kB
> lowmem_reserve[]: 0 0 0 959
> Movable free:3644kB min:1980kB low:2960kB high:3940kB active_anon:738560kB inactive_anon:261340kB active_file:188kB inactive_file:640kB unevictable:0kB writepending:20kB present:1048444kB managed:1010816kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:832kB local_pcp:60kB free_cma:0kB
> lowmem_reserve[]: 0 0 0 0
> DMA: 1*4kB (E) 0*8kB 18*16kB (E) 10*32kB (E) 10*64kB (E) 9*128kB (ME) 8*256kB (E) 2*512kB (E) 2*1024kB (E) 0*2048kB 0*4096kB = 7524kB
> DMA32: 417*4kB (UMEH) 181*8kB (UMEH) 68*16kB (UMEH) 48*32kB (UMEH) 14*64kB (MH) 3*128kB (M) 1*256kB (H) 1*512kB (M) 2*1024kB (M) 0*2048kB 0*4096kB = 9836kB
> Movable: 1*4kB (M) 1*8kB (M) 1*16kB (M) 1*32kB (M) 0*64kB 1*128kB (M) 2*256kB (M) 4*512kB (M) 1*1024kB (M) 0*2048kB 0*4096kB = 3772kB
> 378 total pagecache pages
> 17 pages in swap cache
> Swap cache stats: add 17325, delete 17302, find 0/27
> Free swap = 978940kB
> Total swap = 1048572kB
> 524157 pages RAM
> 0 pages HighMem/MovableOnly
> 12629 pages reserved
> 0 pages cma reserved
> 0 pages hwpoisoned
> [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
> [ 433] 0 433 4904 5 14 3 82 0 upstart-udev-br
> [ 438] 0 438 12371 5 27 3 191 -1000 systemd-udevd
>
> With investigation, skipping page of isolate_lru_pages makes reclaim
> void because it returns zero nr_taken easily so LRU shrinking is
> effectively nothing and just increases priority aggressively.
> Finally, OOM happens.
>
> The problem is that get_scan_count determines nr_to_scan with
> eligible zones so although priority drops to zero, it couldn't
> reclaim any pages if the LRU contains mostly ineligible pages.
>
> get_scan_count:
>
> size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx);
> size = size >> sc->priority;
>
> Assumes sc->priority is 0 and LRU list is as follows.
>
> N-N-N-N-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H-H
>
> (Ie, small eligible pages are in the head of LRU but others are
> almost ineligible pages)
>
> In that case, size becomes 4 so VM want to scan 4 pages but 4 pages
> from tail of the LRU are not eligible pages.
> If get_scan_count counts skipped pages, it doesn't reclaim any pages
> remained after scanning 4 pages so it ends up OOM happening.
>
> This patch makes isolate_lru_pages try to scan pages until it
> encounters eligible zones's pages.
>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] mm, thp: copying user pages must schedule on collapse
From: Vlastimil Babka @ 2017-05-11 9:51 UTC (permalink / raw)
To: David Rientjes, Andrew Morton
Cc: Kirill A. Shutemov, Johannes Weiner, Mel Gorman, linux-kernel,
linux-mm
In-Reply-To: <alpine.DEB.2.10.1705101426380.109808@chino.kir.corp.google.com>
On 05/10/2017 11:27 PM, David Rientjes wrote:
> We have encountered need_resched warnings in __collapse_huge_page_copy()
> while doing {clear,copy}_user_highpage() over HPAGE_PMD_NR source pages.
>
> mm->mmap_sem is held for write, but the iteration is well bounded.
>
> Reschedule as needed.
>
> Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> mm/khugepaged.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -612,7 +612,8 @@ static void __collapse_huge_page_copy(pte_t *pte, struct page *page,
> spinlock_t *ptl)
> {
> pte_t *_pte;
> - for (_pte = pte; _pte < pte+HPAGE_PMD_NR; _pte++) {
> + for (_pte = pte; _pte < pte + HPAGE_PMD_NR;
> + _pte++, page++, address += PAGE_SIZE) {
> pte_t pteval = *_pte;
> struct page *src_page;
>
> @@ -651,9 +652,7 @@ static void __collapse_huge_page_copy(pte_t *pte, struct page *page,
> spin_unlock(ptl);
> free_page_and_swap_cache(src_page);
> }
> -
> - address += PAGE_SIZE;
> - page++;
> + cond_resched();
> }
> }
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 0/7] Introduce ZONE_CMA
From: Michal Hocko @ 2017-05-11 9:13 UTC (permalink / raw)
To: Joonsoo Kim
Cc: Andrew Morton, Rik van Riel, Johannes Weiner, mgorman,
Laura Abbott, Minchan Kim, Marek Szyprowski, Michal Nazarewicz,
Aneesh Kumar K . V, Vlastimil Babka, Russell King, Will Deacon,
linux-mm, linux-kernel, kernel-team
In-Reply-To: <20170511021240.GA22319@js1304-desktop>
On Thu 11-05-17 11:12:43, Joonsoo Kim wrote:
> Sorry for the late response. I was on a vacation.
>
> On Tue, May 02, 2017 at 03:32:29PM +0200, Michal Hocko wrote:
> > On Tue 02-05-17 13:01:32, Joonsoo Kim wrote:
> > > On Thu, Apr 27, 2017 at 05:06:36PM +0200, Michal Hocko wrote:
> > [...]
> > > > I see this point and I agree that using a specific zone might be a
> > > > _nicer_ solution in the end but you have to consider another aspects as
> > > > well. The main one I am worried about is a long term maintainability.
> > > > We are really out of page flags and consuming one for a rather specific
> > > > usecase is not good. Look at ZONE_DMA. I am pretty sure that almost
> > > > no sane HW needs 16MB zone anymore, yet we have hard time to get rid
> > > > of it and so we have that memory laying around unused all the time
> > > > and blocking one page flag bit. CMA falls into a similar category
> > > > AFAIU. I wouldn't be all that surprised if a future HW will not need CMA
> > > > allocations in few years, yet we will have to fight to get rid of it
> > > > like we do with ZONE_DMA. And not only that. We will also have to fight
> > > > finding page flags for other more general usecases in the meantime.
> > >
> > > This maintenance problem is inherent. This problem exists even if we
> > > uses MIGRATETYPE approach. We cannot remove many hooks for CMA if a
> > > future HW will not need CMA allocation in few years. The only
> > > difference is that one takes single zone bit only for CMA user and the
> > > other approach takes many hooks that we need to take care about it all
> > > the time.
> >
> > And I consider this a big difference. Because while hooks are not nice
> > they will affect CMA users (in a sense of bugs/performance etc.). While
> > an additional bit consumed will affect potential future and more generic
> > features.
>
> Because these hooks are so tricky and are spread on many places,
> bugs about these hooks can be made by *non-CMA* user and they hurt
> *CMA* user. These hooks could also delay non-CMA user's development speed
> since there are many hooks about CMA and understanding how CMA is managed
> is rather difficult.
Than make those hooks easier to maintain. Seriously this is a
non-argument.
[...]
> > And all this can be isolated to CMA specific hooks with mostly minimum
> > impact to most users. I hear you saying that zone approach is more natural
> > and I would agree if we wouldn't have to care about the number of zones.
>
> I attach a solution about one more bit in page flags although I don't
> agree with your opinion that additional bit is no-go approach. Just
> note that we have already used three bits for zone encoding in some
> configuration due to ZONE_DEVICE.
I am absolutely not happy about ZONE_DEVICE but there is _no_ other
viable solution right now. I know that people behind this are still
considering struct page over direct pfn usage but they are not in the
same situation as CMA which _can_ work without additional zone.
If you _really_ insist on using zone for CMA then reuse ZONE_MOVABLE.
I absolutely miss why do you push a specialized zone so hard.
[...]
> > No, but I haven't heard any single argument that those bugs are
> > impossible to fix with the current approach. They might be harder to fix
> > but if I can chose between harder for CMA and harder for other more
> > generic HW independent features I will go for the first one. And do not
> > take me wrong, I have nothing against CMA as such. It solves a real life
> > problem. I just believe it doesn't deserve to consume a new bit in page
> > flags because that is just too scarce resource.
>
> As I mentioned above, I think that maintenance overhead due to CMA
> deserves to consume a new bit in page flags. It also provide us
> extendability to introduce more zones in the future.
>
> Anyway, this value-judgement is subjective so I guess that we
> cannot agree with each other. To solve your concern,
> I make following solution. Please let me know your opinion about this.
> This patch can be applied on top of my ZONE_CMA series.
I don not think this makes situation any easier or more acceptable for
merging.
But I feel we are looping without much progress. So let me NAK this
until it is _proven_ that the current code is unfixable nor ZONE_MOVABLE
can be reused
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 0/7] Introduce ZONE_CMA
From: Vlastimil Babka @ 2017-05-11 8:51 UTC (permalink / raw)
To: Michal Hocko
Cc: Joonsoo Kim, Andrew Morton, Rik van Riel, Johannes Weiner,
mgorman, Laura Abbott, Minchan Kim, Marek Szyprowski,
Michal Nazarewicz, Aneesh Kumar K . V, Russell King, Will Deacon,
linux-mm, linux-kernel, kernel-team, Heiko Carstens,
Martin Schwidefsky
In-Reply-To: <20170504124648.GG31540@dhcp22.suse.cz>
On 05/04/2017 02:46 PM, Michal Hocko wrote:
> On Thu 04-05-17 14:33:24, Vlastimil Babka wrote:
>>>
>>> I am pretty sure s390 and ppc support NUMA and aim at supporting really
>>> large systems.
>>
>> I don't see ppc there,
>
> config KVM_BOOK3S_64_HV
> tristate "KVM for POWER7 and later using hypervisor mode in host"
> depends on KVM_BOOK3S_64 && PPC_POWERNV
> select KVM_BOOK3S_HV_POSSIBLE
> select MMU_NOTIFIER
> select CMA
>
> fa61a4e376d21 tries to explain some more
Uh, that's unfortunate then.
> [...]
>>> Are we really ready to add another thing like that? How are distribution
>>> kernels going to handle that?
>>
>> I still hope that generic enterprise/desktop distributions can disable
>> it, and it's only used for small devices with custom kernels.
>>
>> The config burden is already there in any case, it just translates to
>> extra migratetype and fastpath hooks, not extra zone and potentially
>> less nodes.
>
> AFAIU the extra migrate type costs nothing when there are no cma
> reservations. And those hooks can be made noop behind static branch
> as well. So distribution kernels do not really have to be afraid of
> enabling CMA currently.
The tradeoff is unfortunate :/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 5/4] dax: Fix PMD data corruption when fault races with write
From: Jan Kara @ 2017-05-11 8:39 UTC (permalink / raw)
To: Ross Zwisler
Cc: Andrew Morton, Jan Kara, Dan Williams, linux-ext4, linux-fsdevel,
linux-nvdimm, linux-mm, stable
In-Reply-To: <20170510172700.18991-1-ross.zwisler@linux.intel.com>
On Wed 10-05-17 11:27:00, Ross Zwisler wrote:
> This is based on a patch from Jan Kara that fixed the equivalent race in
> the DAX PTE fault path.
>
> Currently DAX PMD read fault can race with write(2) in the following way:
>
> CPU1 - write(2) CPU2 - read fault
> dax_iomap_pmd_fault()
> ->iomap_begin() - sees hole
>
> dax_iomap_rw()
> iomap_apply()
> ->iomap_begin - allocates blocks
> dax_iomap_actor()
> invalidate_inode_pages2_range()
> - there's nothing to invalidate
>
> grab_mapping_entry()
> - we add huge zero page to the radix tree
> and map it to page tables
>
> The result is that hole page is mapped into page tables (and thus zeros
> are seen in mmap) while file has data written in that place.
>
> Fix the problem by locking exception entry before mapping blocks for the
> fault. That way we are sure invalidate_inode_pages2_range() call for
> racing write will either block on entry lock waiting for the fault to
> finish (and unmap stale page tables after that) or read fault will see
> already allocated blocks by write(2).
>
> Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
> Fixes: 9f141d6ef6258a3a37a045842d9ba7e68f368956
> CC: stable@vger.kernel.org
> ---
>
> Jan, I just realized that we need an equivalent fix in the PMD path. Let's
> keep this with the rest of your series so they get applied together,
> applied to stable together, etc.
>
> This applies cleanly to the current linux/master (56868a460b83) + the four
> patches from Jan's series. I've run it through xfstests and some targeted
> testing for the PMD path.
Ah, right. Thanks for fixing it up. The patch looks good. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/dax.c | 28 ++++++++++++++--------------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/fs/dax.c b/fs/dax.c
> index 32f020c..93ae872 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1388,6 +1388,16 @@ static int dax_iomap_pmd_fault(struct vm_fault *vmf,
> goto fallback;
>
> /*
> + * grab_mapping_entry() will make sure we get a 2M empty entry, a DAX
> + * PMD or a HZP entry. If it can't (because a 4k page is already in
> + * the tree, for instance), it will return -EEXIST and we just fall
> + * back to 4k entries.
> + */
> + entry = grab_mapping_entry(mapping, pgoff, RADIX_DAX_PMD);
> + if (IS_ERR(entry))
> + goto fallback;
> +
> + /*
> * Note that we don't use iomap_apply here. We aren't doing I/O, only
> * setting up a mapping, so really we're using iomap_begin() as a way
> * to look up our filesystem block.
> @@ -1395,21 +1405,11 @@ static int dax_iomap_pmd_fault(struct vm_fault *vmf,
> pos = (loff_t)pgoff << PAGE_SHIFT;
> error = ops->iomap_begin(inode, pos, PMD_SIZE, iomap_flags, &iomap);
> if (error)
> - goto fallback;
> + goto unlock_entry;
>
> if (iomap.offset + iomap.length < pos + PMD_SIZE)
> goto finish_iomap;
>
> - /*
> - * grab_mapping_entry() will make sure we get a 2M empty entry, a DAX
> - * PMD or a HZP entry. If it can't (because a 4k page is already in
> - * the tree, for instance), it will return -EEXIST and we just fall
> - * back to 4k entries.
> - */
> - entry = grab_mapping_entry(mapping, pgoff, RADIX_DAX_PMD);
> - if (IS_ERR(entry))
> - goto finish_iomap;
> -
> switch (iomap.type) {
> case IOMAP_MAPPED:
> result = dax_pmd_insert_mapping(vmf, &iomap, pos, &entry);
> @@ -1417,7 +1417,7 @@ static int dax_iomap_pmd_fault(struct vm_fault *vmf,
> case IOMAP_UNWRITTEN:
> case IOMAP_HOLE:
> if (WARN_ON_ONCE(write))
> - goto unlock_entry;
> + break;
> result = dax_pmd_load_hole(vmf, &iomap, &entry);
> break;
> default:
> @@ -1425,8 +1425,6 @@ static int dax_iomap_pmd_fault(struct vm_fault *vmf,
> break;
> }
>
> - unlock_entry:
> - put_locked_mapping_entry(mapping, pgoff, entry);
> finish_iomap:
> if (ops->iomap_end) {
> int copied = PMD_SIZE;
> @@ -1442,6 +1440,8 @@ static int dax_iomap_pmd_fault(struct vm_fault *vmf,
> ops->iomap_end(inode, pos, PMD_SIZE, copied, iomap_flags,
> &iomap);
> }
> + unlock_entry:
> + put_locked_mapping_entry(mapping, pgoff, entry);
> fallback:
> if (result == VM_FAULT_FALLBACK) {
> split_huge_pmd(vma, vmf->pmd, vmf->address);
> --
> 2.9.3
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [v3 0/9] parallelized "struct page" zeroing
From: Michal Hocko @ 2017-05-11 8:05 UTC (permalink / raw)
To: David Miller
Cc: pasha.tatashin, linux-kernel, sparclinux, linux-mm, linuxppc-dev,
linux-s390, borntraeger, heiko.carstens
In-Reply-To: <20170510.111943.1940354761418085760.davem@davemloft.net>
On Wed 10-05-17 11:19:43, David S. Miller wrote:
> From: Michal Hocko <mhocko@kernel.org>
> Date: Wed, 10 May 2017 16:57:26 +0200
>
> > Have you measured that? I do not think it would be super hard to
> > measure. I would be quite surprised if this added much if anything at
> > all as the whole struct page should be in the cache line already. We do
> > set reference count and other struct members. Almost nobody should be
> > looking at our page at this time and stealing the cache line. On the
> > other hand a large memcpy will basically wipe everything away from the
> > cpu cache. Or am I missing something?
>
> I guess it might be clearer if you understand what the block
> initializing stores do on sparc64. There are no memory accesses at
> all.
>
> The cpu just zeros out the cache line, that's it.
>
> No L3 cache line is allocated. So this "wipe everything" behavior
> will not happen in the L3.
OK, good to know. My undestanding of sparc64 is close to zero.
Anyway, do you agree that doing the struct page initialization along
with other writes to it shouldn't add a measurable overhead comparing
to pre-zeroing of larger block of struct pages? We already have an
exclusive cache line and doing one 64B write along with few other stores
should be basically the same.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox