* Re: [patch v2] mm, vmscan: avoid thrashing anon lru when free + file is low
From: Michal Hocko @ 2017-05-03 6:15 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Minchan Kim, Johannes Weiner, Mel Gorman,
linux-kernel, linux-mm
In-Reply-To: <alpine.DEB.2.10.1705021331450.116499@chino.kir.corp.google.com>
On Tue 02-05-17 13:41:23, David Rientjes wrote:
> On Tue, 2 May 2017, Michal Hocko wrote:
>
> > I have already asked and my questions were ignored. So let me ask again
> > and hopefuly not get ignored this time. So Why do we need a different
> > criterion on anon pages than file pages?
>
> The preference in get_scan_count() as already implemented is to reclaim
> from file pages if there is enough memory on the inactive list to reclaim.
> That is unchanged with this patch.
My fault, I was too vague. My question was basically why should we use
a different criterion to SCAN_ANON than SCAN_FILE.
> > I do agree that blindly
> > scanning anon pages when file pages are low is very suboptimal but this
> > adds yet another heuristic without _any_ numbers. Why cannot we simply
> > treat anon and file pages equally? Something like the following
> >
> > if (pgdatfile + pgdatanon + pgdatfree > 2*total_high_wmark) {
> > scan_balance = SCAN_FILE;
> > if (pgdatfile < pgdatanon)
> > scan_balance = SCAN_ANON;
> > goto out;
> > }
> >
>
> This would be substantially worse than the current code because it
> thrashes the anon lru when anon out numbers file pages rather than at the
> point we fall under the high watermarks for all eligible zones. If you
> tested your suggestion, you could see gigabytes of memory left untouched
> on the file lru. Anonymous memory is more probable to be part of the
> working set.
This was supposed to be more an example of a direction I was thinking,
definitely not a final patch. I will think more to come up with a
more complete proposal.
> > Also it would help to describe the workload which can trigger this
> > behavior so that we can compare numbers before and after this patch.
>
> Any workload that fills system RAM with anonymous memory that cannot be
> reclaimed will thrash the anon lru without this patch.
I have already asked, but I do not understand why this anon memory
couldn't be reclaimed. Who is pinning it? Why cannot it be swapped out?
If it is mlocked it should be moved to unevictable LRU. What am I
missing?
--
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] vmscan: scan pages until it founds eligible pages
From: Michal Hocko @ 2017-05-03 6:00 UTC (permalink / raw)
To: Minchan Kim, Johannes Weiner
Cc: Andrew Morton, Mel Gorman, kernel-team, linux-kernel, linux-mm
In-Reply-To: <20170503044809.GA21619@bgram>
On Wed 03-05-17 13:48:09, Minchan Kim wrote:
> On Tue, May 02, 2017 at 05:14:36PM +0200, Michal Hocko wrote:
> > On Tue 02-05-17 23:51:50, Minchan Kim wrote:
> > > Hi Michal,
> > >
> > > On Tue, May 02, 2017 at 09:54:32AM +0200, Michal Hocko wrote:
> > > > On Tue 02-05-17 14:14:52, Minchan Kim wrote:
> > > > > Oops, forgot to add lkml and linux-mm.
> > > > > Sorry for that.
> > > > > Send it again.
> > > > >
> > > > > >From 8ddf1c8aa15baf085bc6e8c62ce705459d57ea4c Mon Sep 17 00:00:00 2001
> > > > > From: Minchan Kim <minchan@kernel.org>
> > > > > Date: Tue, 2 May 2017 12:34:05 +0900
> > > > > Subject: [PATCH] vmscan: scan pages until it founds eligible pages
> > > > >
> > > > > On Tue, May 02, 2017 at 01:40:38PM +0900, Minchan Kim wrote:
> > > > > There are premature OOM happening. Although there are a ton of free
> > > > > swap and anonymous LRU list of elgible zones, OOM happened.
> > > > >
> > > > > 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.
> > > >
> > > > I am not really sure I understand the problem you are facing. Could you
> > > > be more specific please? What is your configuration etc...
> > >
> > > Sure, KVM guest on x86_64, It has 2G memory and 1G swap and configured
> > > movablecore=1G to simulate highmem zone.
> > > Workload is a process consumes 2.2G memory and then random touch the
> > > address space so it makes lots of swap in/out.
> > >
> > > >
> > > > > balloon invoked oom-killer: gfp_mask=0x17080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), nodemask=(null), order=0, oom_score_adj=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
> > > >
> > > > Hmm DMA32 has sufficient free memory to allow this order-0 request.
> > > > Inactive anon lru is basically empty. Why do not we rotate a really
> > > > large active anon list? Isn't this the primary problem?
> > >
> > > It's a side effect by skipping page logic in isolate_lru_pages
> > > I mentioned above in changelog.
> > >
> > > The problem is a lot of anonymous memory in movable zone(ie, highmem)
> > > and non-small memory in DMA32 zone.
> >
> > Such a configuration is questionable on its own. But let't keep this
> > part alone.
>
> It seems you are misunderstood. It's really common on 32bit.
Yes, I am not arguing about 32b systems. It is quite common to see
issues which are inherent to the highmem zone.
> Think of 2G DRAM system on 32bit. Normally, it's 1G normal:1G highmem.
> It's almost same with one I configured.
>
> >
> > > In heavy memory pressure,
> > > requesting a page in GFP_KERNEL triggers reclaim. VM knows inactive list
> > > is low so it tries to deactivate pages. For it, first of all, it tries
> > > to isolate pages from active list but there are lots of anonymous pages
> > > from movable zone so skipping logic in isolate_lru_pages works. With
> > > the result, isolate_lru_pages cannot isolate any eligible pages so
> > > reclaim trial is effectively void. It continues to meet OOM.
> >
> > But skipped pages should be rotated and we should eventually hit pages
> > from the right zone(s). Moreover we should scan the full LRU at priority
> > 0 so why exactly we hit the OOM killer?
>
> Yes, full scan in priority 0 but keep it in mind that the number of full
> LRU pages to scan is one of eligible pages, not all pages of the node.
I have hard time understanding what you are trying to say here.
> And isolate_lru_pages have accounted skipped pages as scan count so that
> VM cannot isolate any pages of eligible pages in LRU if non-eligible pages
> are a lot in the LRU.
>
> >
> > Anyway [1] has changed this behavior. Are you seeing the issue with this
> > patch dropped?
>
> Good point. Before the patch, it didn't increase scan count with skipped
> pages so with reverting [1], I guess it might work but worry about
> isolating lots of skipped pages into temporal pages_skipped list which
> might causes premate OOM. Anyway, I will test it when I returns at
> office after vacation.
I do not think we want to drop this patch. I think we might be good
enough to simply fold this into the patch
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 24efcc20af91..ac146f10f222 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1472,7 +1472,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan,
LIST_HEAD(pages_skipped);
for (scan = 0; scan < nr_to_scan && nr_taken < nr_to_scan &&
- !list_empty(src); scan++) {
+ !list_empty(src);) {
struct page *page;
page = lru_to_page(src);
@@ -1486,6 +1486,12 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan,
continue;
}
+ /*
+ * Do not count skipped pages because we do want to isolate
+ * some pages even when the LRU mostly contains ineligible
+ * pages
+ */
+ scan++;
switch (__isolate_lru_page(page, mode)) {
case 0:
nr_pages = hpage_nr_pages(page);
What do you think Johannes?
> > [1] http://www.ozlabs.org/~akpm/mmotm/broken-out/revert-mm-vmscan-account-for-skipped-pages-as-a-partial-scan.patch
> > --
> > Michal Hocko
> > SUSE Labs
--
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 related
* Re: [PATCH] vmscan: scan pages until it founds eligible pages
From: Minchan Kim @ 2017-05-03 4:48 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Johannes Weiner, Mel Gorman, kernel-team,
linux-kernel, linux-mm
In-Reply-To: <20170502151436.GN14593@dhcp22.suse.cz>
On Tue, May 02, 2017 at 05:14:36PM +0200, Michal Hocko wrote:
> On Tue 02-05-17 23:51:50, Minchan Kim wrote:
> > Hi Michal,
> >
> > On Tue, May 02, 2017 at 09:54:32AM +0200, Michal Hocko wrote:
> > > On Tue 02-05-17 14:14:52, Minchan Kim wrote:
> > > > Oops, forgot to add lkml and linux-mm.
> > > > Sorry for that.
> > > > Send it again.
> > > >
> > > > >From 8ddf1c8aa15baf085bc6e8c62ce705459d57ea4c Mon Sep 17 00:00:00 2001
> > > > From: Minchan Kim <minchan@kernel.org>
> > > > Date: Tue, 2 May 2017 12:34:05 +0900
> > > > Subject: [PATCH] vmscan: scan pages until it founds eligible pages
> > > >
> > > > On Tue, May 02, 2017 at 01:40:38PM +0900, Minchan Kim wrote:
> > > > There are premature OOM happening. Although there are a ton of free
> > > > swap and anonymous LRU list of elgible zones, OOM happened.
> > > >
> > > > 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.
> > >
> > > I am not really sure I understand the problem you are facing. Could you
> > > be more specific please? What is your configuration etc...
> >
> > Sure, KVM guest on x86_64, It has 2G memory and 1G swap and configured
> > movablecore=1G to simulate highmem zone.
> > Workload is a process consumes 2.2G memory and then random touch the
> > address space so it makes lots of swap in/out.
> >
> > >
> > > > balloon invoked oom-killer: gfp_mask=0x17080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), nodemask=(null), order=0, oom_score_adj=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
> > >
> > > Hmm DMA32 has sufficient free memory to allow this order-0 request.
> > > Inactive anon lru is basically empty. Why do not we rotate a really
> > > large active anon list? Isn't this the primary problem?
> >
> > It's a side effect by skipping page logic in isolate_lru_pages
> > I mentioned above in changelog.
> >
> > The problem is a lot of anonymous memory in movable zone(ie, highmem)
> > and non-small memory in DMA32 zone.
>
> Such a configuration is questionable on its own. But let't keep this
> part alone.
It seems you are misunderstood. It's really common on 32bit.
Think of 2G DRAM system on 32bit. Normally, it's 1G normal:1G highmem.
It's almost same with one I configured.
>
> > In heavy memory pressure,
> > requesting a page in GFP_KERNEL triggers reclaim. VM knows inactive list
> > is low so it tries to deactivate pages. For it, first of all, it tries
> > to isolate pages from active list but there are lots of anonymous pages
> > from movable zone so skipping logic in isolate_lru_pages works. With
> > the result, isolate_lru_pages cannot isolate any eligible pages so
> > reclaim trial is effectively void. It continues to meet OOM.
>
> But skipped pages should be rotated and we should eventually hit pages
> from the right zone(s). Moreover we should scan the full LRU at priority
> 0 so why exactly we hit the OOM killer?
Yes, full scan in priority 0 but keep it in mind that the number of full
LRU pages to scan is one of eligible pages, not all pages of the node.
And isolate_lru_pages have accounted skipped pages as scan count so that
VM cannot isolate any pages of eligible pages in LRU if non-eligible pages
are a lot in the LRU.
>
> Anyway [1] has changed this behavior. Are you seeing the issue with this
> patch dropped?
Good point. Before the patch, it didn't increase scan count with skipped
pages so with reverting [1], I guess it might work but worry about
isolating lots of skipped pages into temporal pages_skipped list which
might causes premate OOM. Anyway, I will test it when I returns at
office after vacation.
Thanks.
>
> [1] http://www.ozlabs.org/~akpm/mmotm/broken-out/revert-mm-vmscan-account-for-skipped-pages-as-a-partial-scan.patch
> --
> 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: 4.11.0-rc8+/x86_64 desktop lockup until applications closed
From: Arthur Marsh @ 2017-05-03 1:41 UTC (permalink / raw)
To: Michal Hocko; +Cc: Linux Kernel Mailing List, linux-mm
In-Reply-To: <20170502073138.GA14593@dhcp22.suse.cz>
Michal Hocko wrote on 02/05/17 17:01:
>> [92311.944443] swap_info_get: Bad swap offset entry 000ffffd
>> [92311.944449] swap_info_get: Bad swap offset entry 000ffffe
>> [92311.944451] swap_info_get: Bad swap offset entry 000fffff
>
> Pte swap entry seem to be clobbered. That suggests a deeper problem and
> a memory corruption.
Thanks again for the feedback. I've gone with 4.11.0+ git head kernels
and last night rather than a lock-up I saw:
[40050.937161] mmap: chromium (6060): VmData 2148573184 exceed data
ulimit 2147483647. Update limits or use boot option ignore_rlimit_data.
[40051.183213] traps: chromium[6060] trap int3 ip:5642ccce7996
sp:7ffe0a563ac0 error:0
and the desktop session remained responsive.
The 2 GiB ulimit is preferable for me than having to rely on the OOM
killer, but I can run tests with ignore_rlimit_data later on to check
that the OOM killer still works rather than hitting some unforeseen
error on swap exhaustion.
Arthur.
--
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, vmalloc: properly track vmalloc users
From: kbuild test robot @ 2017-05-03 1:29 UTC (permalink / raw)
To: Michal Hocko
Cc: kbuild-all, Andrew Morton, Vlastimil Babka, linux-mm, LKML,
Michal Hocko
In-Reply-To: <20170502134657.12381-1-mhocko@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4363 bytes --]
Hi Michal,
[auto build test ERROR on mmotm/master]
[also build test ERROR on next-20170502]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Michal-Hocko/mm-vmalloc-properly-track-vmalloc-users/20170503-065022
base: git://git.cmpxchg.org/linux-mmotm.git master
config: m68k-multi_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All errors (new ones prefixed by >>):
In file included from arch/m68k/include/asm/pgtable_mm.h:147:0,
from arch/m68k/include/asm/pgtable.h:4,
from include/linux/vmalloc.h:9,
from fs/nfsd/nfscache.c:12:
arch/m68k/include/asm/motorola_pgtable.h: In function 'pgd_offset':
>> arch/m68k/include/asm/motorola_pgtable.h:198:11: error: dereferencing pointer to incomplete type
return mm->pgd + pgd_index(address);
^
vim +198 arch/m68k/include/asm/motorola_pgtable.h
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 182 }
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 183 static inline pte_t pte_mkcache(pte_t pte)
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 184 {
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 185 pte_val(pte) = (pte_val(pte) & _CACHEMASK040) | m68k_supervisor_cachemode;
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 186 return pte;
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 187 }
7e675137 include/asm-m68k/motorola_pgtable.h Nick Piggin 2008-04-28 188 static inline pte_t pte_mkspecial(pte_t pte) { return pte; }
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 189
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 190 #define PAGE_DIR_OFFSET(tsk,address) pgd_offset((tsk),(address))
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 191
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 192 #define pgd_index(address) ((address) >> PGDIR_SHIFT)
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 193
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 194 /* to find an entry in a page-table-directory */
5b808a59 include/asm-m68k/motorola_pgtable.h Geert Uytterhoeven 2008-02-07 195 static inline pgd_t *pgd_offset(const struct mm_struct *mm,
5b808a59 include/asm-m68k/motorola_pgtable.h Geert Uytterhoeven 2008-02-07 196 unsigned long address)
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 197 {
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 @198 return mm->pgd + pgd_index(address);
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 199 }
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 200
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 201 #define swapper_pg_dir kernel_pg_dir
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 202 extern pgd_t kernel_pg_dir[128];
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 203
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 204 static inline pgd_t *pgd_offset_k(unsigned long address)
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 205 {
^1da177e include/asm-m68k/motorola_pgtable.h Linus Torvalds 2005-04-16 206 return kernel_pg_dir + (address >> PGDIR_SHIFT);
:::::: The code at line 198 was first introduced by commit
:::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:::::: TO: Linus Torvalds <torvalds@ppc970.osdl.org>
:::::: CC: Linus Torvalds <torvalds@ppc970.osdl.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 13571 bytes --]
^ permalink raw reply
* Re: [PATCH] mm, vmalloc: properly track vmalloc users
From: kbuild test robot @ 2017-05-03 0:52 UTC (permalink / raw)
To: Michal Hocko
Cc: kbuild-all, Andrew Morton, Vlastimil Babka, linux-mm, LKML,
Michal Hocko
In-Reply-To: <20170502134657.12381-1-mhocko@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 5669 bytes --]
Hi Michal,
[auto build test ERROR on mmotm/master]
[also build test ERROR on next-20170502]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Michal-Hocko/mm-vmalloc-properly-track-vmalloc-users/20170503-065022
base: git://git.cmpxchg.org/linux-mmotm.git master
config: m68k-m5475evb_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All error/warnings (new ones prefixed by >>):
In file included from arch/m68k/include/asm/pgtable_mm.h:145:0,
from arch/m68k/include/asm/pgtable.h:4,
from include/linux/vmalloc.h:9,
from arch/m68k/kernel/module.c:9:
arch/m68k/include/asm/mcf_pgtable.h: In function 'nocache_page':
>> arch/m68k/include/asm/mcf_pgtable.h:339:43: error: 'init_mm' undeclared (first use in this function)
#define pgd_offset_k(address) pgd_offset(&init_mm, address)
^
arch/m68k/include/asm/mcf_pgtable.h:334:35: note: in definition of macro 'pgd_offset'
#define pgd_offset(mm, address) ((mm)->pgd + pgd_index(address))
^
>> arch/m68k/include/asm/mcf_pgtable.h:366:8: note: in expansion of macro 'pgd_offset_k'
dir = pgd_offset_k(addr);
^
arch/m68k/include/asm/mcf_pgtable.h:339:43: note: each undeclared identifier is reported only once for each function it appears in
#define pgd_offset_k(address) pgd_offset(&init_mm, address)
^
arch/m68k/include/asm/mcf_pgtable.h:334:35: note: in definition of macro 'pgd_offset'
#define pgd_offset(mm, address) ((mm)->pgd + pgd_index(address))
^
>> arch/m68k/include/asm/mcf_pgtable.h:366:8: note: in expansion of macro 'pgd_offset_k'
dir = pgd_offset_k(addr);
^
arch/m68k/include/asm/mcf_pgtable.h: In function 'cache_page':
>> arch/m68k/include/asm/mcf_pgtable.h:339:43: error: 'init_mm' undeclared (first use in this function)
#define pgd_offset_k(address) pgd_offset(&init_mm, address)
^
arch/m68k/include/asm/mcf_pgtable.h:334:35: note: in definition of macro 'pgd_offset'
#define pgd_offset(mm, address) ((mm)->pgd + pgd_index(address))
^
arch/m68k/include/asm/mcf_pgtable.h:382:8: note: in expansion of macro 'pgd_offset_k'
dir = pgd_offset_k(addr);
^
vim +/init_mm +339 arch/m68k/include/asm/mcf_pgtable.h
91521c2e Greg Ungerer 2011-10-14 333 #define pgd_index(address) ((address) >> PGDIR_SHIFT)
91521c2e Greg Ungerer 2011-10-14 334 #define pgd_offset(mm, address) ((mm)->pgd + pgd_index(address))
91521c2e Greg Ungerer 2011-10-14 335
91521c2e Greg Ungerer 2011-10-14 336 /*
91521c2e Greg Ungerer 2011-10-14 337 * Find an entry in a kernel pagetable directory.
91521c2e Greg Ungerer 2011-10-14 338 */
91521c2e Greg Ungerer 2011-10-14 @339 #define pgd_offset_k(address) pgd_offset(&init_mm, address)
91521c2e Greg Ungerer 2011-10-14 340
91521c2e Greg Ungerer 2011-10-14 341 /*
91521c2e Greg Ungerer 2011-10-14 342 * Find an entry in the second-level pagetable.
91521c2e Greg Ungerer 2011-10-14 343 */
91521c2e Greg Ungerer 2011-10-14 344 static inline pmd_t *pmd_offset(pgd_t *pgd, unsigned long address)
91521c2e Greg Ungerer 2011-10-14 345 {
91521c2e Greg Ungerer 2011-10-14 346 return (pmd_t *) pgd;
91521c2e Greg Ungerer 2011-10-14 347 }
91521c2e Greg Ungerer 2011-10-14 348
91521c2e Greg Ungerer 2011-10-14 349 /*
91521c2e Greg Ungerer 2011-10-14 350 * Find an entry in the third-level pagetable.
91521c2e Greg Ungerer 2011-10-14 351 */
91521c2e Greg Ungerer 2011-10-14 352 #define __pte_offset(address) ((address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1))
91521c2e Greg Ungerer 2011-10-14 353 #define pte_offset_kernel(dir, address) \
91521c2e Greg Ungerer 2011-10-14 354 ((pte_t *) __pmd_page(*(dir)) + __pte_offset(address))
91521c2e Greg Ungerer 2011-10-14 355
91521c2e Greg Ungerer 2011-10-14 356 /*
91521c2e Greg Ungerer 2011-10-14 357 * Disable caching for page at given kernel virtual address.
91521c2e Greg Ungerer 2011-10-14 358 */
91521c2e Greg Ungerer 2011-10-14 359 static inline void nocache_page(void *vaddr)
91521c2e Greg Ungerer 2011-10-14 360 {
91521c2e Greg Ungerer 2011-10-14 361 pgd_t *dir;
91521c2e Greg Ungerer 2011-10-14 362 pmd_t *pmdp;
91521c2e Greg Ungerer 2011-10-14 363 pte_t *ptep;
91521c2e Greg Ungerer 2011-10-14 364 unsigned long addr = (unsigned long) vaddr;
91521c2e Greg Ungerer 2011-10-14 365
91521c2e Greg Ungerer 2011-10-14 @366 dir = pgd_offset_k(addr);
91521c2e Greg Ungerer 2011-10-14 367 pmdp = pmd_offset(dir, addr);
91521c2e Greg Ungerer 2011-10-14 368 ptep = pte_offset_kernel(pmdp, addr);
91521c2e Greg Ungerer 2011-10-14 369 *ptep = pte_mknocache(*ptep);
:::::: The code at line 339 was first introduced by commit
:::::: 91521c2ea6e3d5a790df40988101ad099ddbf7c8 m68k: page table support definitions and code for ColdFire MMU
:::::: TO: Greg Ungerer <gerg@uclinux.org>
:::::: CC: Greg Ungerer <gerg@uclinux.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 6516 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] hugetlbfs 'noautofill' mount option
From: Dave Hansen @ 2017-05-02 23:43 UTC (permalink / raw)
To: Prakash Sangappa, linux-kernel, linux-mm
In-Reply-To: <03127895-3c5a-5182-82de-3baa3116749e@oracle.com>
On 05/02/2017 04:34 PM, Prakash Sangappa wrote:
> Similarly, a madvise() option also requires additional system call by every
> process mapping the file, this is considered a overhead for the database.
How long-lived are these processes? For a database, I'd assume that
this would happen a single time, or a single time per mmap() at process
startup time. Such a syscall would be doing something on the order of
taking mmap_sem, walking the VMA tree, setting a bit per VMA, and
unlocking. That's a pretty cheap one-time cost...
> If we do consider a new madvise() option, will it be acceptable
> since this will be specifically for hugetlbfs file mappings?
Ideally, it would be something that is *not* specifically for hugetlbfs.
MADV_NOAUTOFILL, for instance, could be defined to SIGSEGV whenever
memory is touched that was not populated with MADV_WILLNEED, mlock(), etc...
> If so,
> would a new flag to mmap() call itself be acceptable, which would
> define the proposed behavior?. That way no additional system calls
> need to be made.
I don't feel super strongly about it, but I guess an mmap() flag could
work too.
--
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 RFC] hugetlbfs 'noautofill' mount option
From: Prakash Sangappa @ 2017-05-02 23:34 UTC (permalink / raw)
To: Dave Hansen, linux-kernel, linux-mm
In-Reply-To: <7ff6fb32-7d16-af4f-d9d5-698ab7e9e14b@intel.com>
On 5/2/17 2:32 PM, Dave Hansen wrote:
> On 05/01/2017 11:00 AM, Prakash Sangappa wrote:
>> This patch adds a new hugetlbfs mount option 'noautofill', to indicate that
>> pages should not be allocated at page fault time when accessed thru mmapped
>> address.
> I think the main argument against doing something like this is further
> specializing hugetlbfs. I was really hoping that userfaultfd would be
> usable for your needs here.
>
> Could you elaborate on other options that you considered? Did you look
> at userfaultfd? What about an madvise() option that disallows backing
> allocations?
Yes, we did consider userfaultfd and madvise(). The use case in mind is
the database.
With a database, large number of single threaded processes are involved
which
will map hugetlbfs file and use it for shared memory. The concern with
using
userfaultfd is the overhead of setup and having an additional thread per
process
to monitor the userfaultfd. Even if the additional thread can be
avoided, by using
an external monitor process and each process sending the userfaultfd to
this
monitor process, setup overhead exists.
Similarly, a madvise() option also requires additional system call by every
process mapping the file, this is considered a overhead for the database.
If we do consider a new madvise() option, will it be acceptable since
this will be
specifically for hugetlbfs file mappings? If so, would a new flag to mmap()
call itself be acceptable, which would define the proposed behavior?.
That way
no additional system calls need to be made. Again this mmap flag would be
applicable specifically to hugetlbfs file mappings
With the proposed mount option, it would enforce one consistent behavior
and the application using this filesystem would not have to take additional
steps as with userfaultfd or madvise().
--
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 RFC] hugetlbfs 'noautofill' mount option
From: Dave Hansen @ 2017-05-02 21:32 UTC (permalink / raw)
To: Prakash Sangappa, linux-kernel, linux-mm
In-Reply-To: <b0efc671-0d7a-0aef-5646-a635478c31b0@oracle.com>
On 05/01/2017 11:00 AM, Prakash Sangappa wrote:
> This patch adds a new hugetlbfs mount option 'noautofill', to indicate that
> pages should not be allocated at page fault time when accessed thru mmapped
> address.
I think the main argument against doing something like this is further
specializing hugetlbfs. I was really hoping that userfaultfd would be
usable for your needs here.
Could you elaborate on other options that you considered? Did you look
at userfaultfd? What about an madvise() option that disallows backing
allocations?
--
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][RFC] mm: make kswapd try harder to keep active pages in cache
From: Josef Bacik @ 2017-05-02 21:27 UTC (permalink / raw)
To: linux-mm, hannes, kernel-team, riel
When testing a slab heavy workload I noticed that we often would barely
reclaim anything at all from slab when kswapd started doing reclaim.
This is because we use the ratio of nr_scanned / nr_lru to determine how
much of slab we should reclaim. But in a slab only/mostly workload we
will not have much page cache to reclaim, and thus our ratio will be
really low and not at all related to where the memory on the system is.
Instead we want to use a ratio of the reclaimable slab to the actual
reclaimable space on the system. That way if we are slab heavy we work
harder to reclaim slab.
The other part of this that hurts is when we are running close to full
memory with our working set. If we start putting a lot of reclaimable
slab pressure on the system (think find /, or some other silliness), we
will happily evict the active pages over the slab cache. This is kind
of backwards as we want to do all that we can to keep the active working
set in memory, and instead evict these short lived objects. The same
thing occurs when say you do a yum update of a few packages while your
working set takes up most of RAM, you end up with inactive lists being
relatively small and so we reclaim active pages even though we could
reclaim these short lived inactive pages.
Enter this patch. I wanted to break it up into two parts but they are
so interlinked that it wasn't really practical. Instead of scanning
active/inactive LRU's together and slab as an afterthought, instead
take a look at the node state from the beginning and purposefully only
considering the inactive LRU's and slab. Then if for example inactive
isn't reclaiming anything but slab is, increase the pressure on the slab
cache until we reclaim what we want, or stop being effective and then
start processing all the LRU's like we normally would.
I have two tests I was using to watch either side of this problem. The
first test kept 2 files that took up 3/4 of the memory, and then started
creating a bunch of empty files. Without this patch we would have to
re-read both files in their entirety at least 3 times during the run.
With this patch the active pages are never evicted.
The second test was a test that would read and stat all the files in a
directory, which again would take up about 3/4 of the memory with slab
cache. Then I cat'ed a 100gib file into /dev/null and checked to see if
any of the files were evicted and verified that none of the files were
evicted.
Signed-off-by: Josef Bacik <jbacik@fb.com>
---
mm/vmscan.c | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 105 insertions(+), 21 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index bc8031e..457583d 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -105,6 +105,9 @@ struct scan_control {
/* One of the zones is ready for compaction */
unsigned int compaction_ready:1;
+ /* Only reclaim inactive page cache or slab. */
+ unsigned int inactive_only:1;
+
/* Incremented by the number of inactive pages that were scanned */
unsigned long nr_scanned;
@@ -309,7 +312,8 @@ EXPORT_SYMBOL(unregister_shrinker);
static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
struct shrinker *shrinker,
unsigned long nr_scanned,
- unsigned long nr_eligible)
+ unsigned long nr_eligible,
+ unsigned long *slab_scanned)
{
unsigned long freed = 0;
unsigned long long delta;
@@ -410,6 +414,9 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
next_deferred -= scanned;
else
next_deferred = 0;
+ if (slab_scanned)
+ (*slab_scanned) += scanned;
+
/*
* move the unused scan count back into the shrinker in a
* manner that handles concurrent updates. If we exhausted the
@@ -456,7 +463,8 @@ static unsigned long do_shrink_slab(struct shrink_control *shrinkctl,
static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
struct mem_cgroup *memcg,
unsigned long nr_scanned,
- unsigned long nr_eligible)
+ unsigned long nr_eligible,
+ unsigned long *slab_scanned)
{
struct shrinker *shrinker;
unsigned long freed = 0;
@@ -464,9 +472,6 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
if (memcg && (!memcg_kmem_enabled() || !mem_cgroup_online(memcg)))
return 0;
- if (nr_scanned == 0)
- nr_scanned = SWAP_CLUSTER_MAX;
-
if (!down_read_trylock(&shrinker_rwsem)) {
/*
* If we would return 0, our callers would understand that we
@@ -497,7 +502,8 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
if (!(shrinker->flags & SHRINKER_NUMA_AWARE))
sc.nid = 0;
- freed += do_shrink_slab(&sc, shrinker, nr_scanned, nr_eligible);
+ freed += do_shrink_slab(&sc, shrinker, nr_scanned, nr_eligible,
+ slab_scanned);
}
up_read(&shrinker_rwsem);
@@ -516,7 +522,7 @@ void drop_slab_node(int nid)
freed = 0;
do {
freed += shrink_slab(GFP_KERNEL, nid, memcg,
- 1000, 1000);
+ 1000, 1000, NULL);
} while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
} while (freed > 10);
}
@@ -2100,6 +2106,7 @@ enum scan_balance {
SCAN_FRACT,
SCAN_ANON,
SCAN_FILE,
+ SCAN_INACTIVE,
};
/*
@@ -2148,6 +2155,11 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
if (!global_reclaim(sc))
force_scan = true;
+ if (sc->inactive_only) {
+ scan_balance = SCAN_INACTIVE;
+ goto out;
+ }
+
/* If we have no swap space, do not bother scanning anon pages. */
if (!sc->may_swap || mem_cgroup_get_nr_swap_pages(memcg) <= 0) {
scan_balance = SCAN_FILE;
@@ -2312,6 +2324,15 @@ static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
scan = 0;
}
break;
+ case SCAN_INACTIVE:
+ if (file && !is_active_lru(lru)) {
+ if (scan && size > sc->nr_to_reclaim)
+ scan = sc->nr_to_reclaim;
+ } else {
+ size = 0;
+ scan = 0;
+ }
+ break;
default:
/* Look ma, no brain */
BUG();
@@ -2536,7 +2557,40 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc)
{
struct reclaim_state *reclaim_state = current->reclaim_state;
unsigned long nr_reclaimed, nr_scanned;
+ unsigned long nr_reclaim, nr_slab, total_high_wmark = 0, nr_inactive;
+ int z;
bool reclaimable = false;
+ bool skip_slab = false;
+
+ nr_slab = sum_zone_node_page_state(pgdat->node_id,
+ NR_SLAB_RECLAIMABLE);
+ nr_inactive = node_page_state(pgdat, NR_INACTIVE_FILE);
+ nr_reclaim = pgdat_reclaimable_pages(pgdat);
+
+ for (z = 0; z < MAX_NR_ZONES; z++) {
+ struct zone *zone = &pgdat->node_zones[z];
+ if (!managed_zone(zone))
+ continue;
+ total_high_wmark += high_wmark_pages(zone);
+ }
+
+ /*
+ * If we don't have a lot of inactive or slab pages then there's no
+ * point in trying to free them exclusively, do the normal scan stuff.
+ */
+ if (nr_inactive < total_high_wmark && nr_slab < total_high_wmark)
+ sc->inactive_only = 0;
+ if (!global_reclaim(sc))
+ sc->inactive_only = 0;
+
+ /*
+ * We still want to slightly prefer slab over inactive, so if inactive
+ * is large enough just skip slab shrinking for now. If we aren't able
+ * to reclaim enough exclusively from the inactive lists then we'll
+ * reset this on the first loop and dip into slab.
+ */
+ if (nr_inactive > total_high_wmark && nr_inactive > nr_slab)
+ skip_slab = true;
do {
struct mem_cgroup *root = sc->target_mem_cgroup;
@@ -2545,6 +2599,8 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc)
.priority = sc->priority,
};
unsigned long node_lru_pages = 0;
+ unsigned long slab_reclaimed = 0;
+ unsigned long slab_scanned = 0;
struct mem_cgroup *memcg;
nr_reclaimed = sc->nr_reclaimed;
@@ -2568,10 +2624,23 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc)
shrink_node_memcg(pgdat, memcg, sc, &lru_pages);
node_lru_pages += lru_pages;
- if (memcg)
- shrink_slab(sc->gfp_mask, pgdat->node_id,
- memcg, sc->nr_scanned - scanned,
- lru_pages);
+ /*
+ * We don't want to put a lot of pressure on all of the
+ * slabs if a memcg is mostly full, so use the ratio of
+ * the lru size to the total reclaimable space on the
+ * system. If we have sc->inactive_only set only use
+ * this node's inactive space to get a more realistic
+ * ratio.
+ */
+ if (memcg && !skip_slab) {
+ unsigned long denominator = nr_reclaim;
+ if (sc->inactive_only)
+ denominator = nr_inactive;
+ slab_reclaimed +=
+ shrink_slab(sc->gfp_mask, pgdat->node_id,
+ memcg, lru_pages, denominator,
+ &slab_scanned);
+ }
/* Record the group's reclaim efficiency */
vmpressure(sc->gfp_mask, memcg, false,
@@ -2595,15 +2664,11 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc)
}
} while ((memcg = mem_cgroup_iter(root, memcg, &reclaim)));
- /*
- * Shrink the slab caches in the same proportion that
- * the eligible LRU pages were scanned.
- */
- if (global_reclaim(sc))
- shrink_slab(sc->gfp_mask, pgdat->node_id, NULL,
- sc->nr_scanned - nr_scanned,
- node_lru_pages);
-
+ if (!skip_slab && global_reclaim(sc))
+ slab_reclaimed += shrink_slab(sc->gfp_mask,
+ pgdat->node_id, NULL,
+ nr_slab, nr_reclaim,
+ &slab_scanned);
if (reclaim_state) {
sc->nr_reclaimed += reclaim_state->reclaimed_slab;
reclaim_state->reclaimed_slab = 0;
@@ -2614,9 +2679,27 @@ static bool shrink_node(pg_data_t *pgdat, struct scan_control *sc)
sc->nr_scanned - nr_scanned,
sc->nr_reclaimed - nr_reclaimed);
- if (sc->nr_reclaimed - nr_reclaimed)
+ if (sc->nr_reclaimed - nr_reclaimed) {
reclaimable = true;
+ } else if (sc->inactive_only && !skip_slab) {
+ unsigned long percent;
+ /*
+ * We didn't reclaim anything this go around, so the
+ * inactive list is likely spent. If we're reclaiming
+ * less than half of the objects in slab that we're
+ * scanning then just stop doing the inactive only scan.
+ * Otherwise ramp up the pressure on the slab caches
+ * hoping that eventually we'll start freeing enough
+ * objects to reclaim space.
+ */
+ percent = (slab_reclaimed * 100 / slab_scanned);
+ if (percent < 50)
+ sc->inactive_only = 0;
+ else
+ nr_slab <<= 1;
+ }
+ skip_slab = false;
} while (should_continue_reclaim(pgdat, sc->nr_reclaimed - nr_reclaimed,
sc->nr_scanned - nr_scanned, sc));
@@ -3210,6 +3293,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx)
.may_writepage = !laptop_mode,
.may_unmap = 1,
.may_swap = 1,
+ .inactive_only = 1,
};
count_vm_event(PAGEOUTRUN);
--
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: [RESENT PATCH] x86/mem: fix the offset overflow when read/write mem
From: David Rientjes @ 2017-05-02 20:54 UTC (permalink / raw)
To: zhongjiang, Bjorn Helgaas, Yoshinori Sato
Cc: Rich Felker, Andrew Morton, arnd, hannes, kirill, mgorman, hughd,
riel, linux-mm, linux-kernel
In-Reply-To: <1493293775-57176-1-git-send-email-zhongjiang@huawei.com>
On Thu, 27 Apr 2017, zhongjiang wrote:
> From: zhong jiang <zhongjiang@huawei.com>
>
> Recently, I found the following issue, it will result in the panic.
>
> [ 168.739152] mmap1: Corrupted page table at address 7f3e6275a002
> [ 168.745039] PGD 61f4a1067
> [ 168.745040] PUD 61ab19067
> [ 168.747730] PMD 61fb8b067
> [ 168.750418] PTE 8000100000000225
> [ 168.753109]
> [ 168.757795] Bad pagetable: 000d [#1] SMP
> [ 168.761696] Modules linked in: intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd iTCO_wdt glue_helper cryptd sg iTCO_vendor_support i7core_edac edac_core shpchp lpc_ich i2c_i801 pcspkr mfd_core acpi_cpufreq ip_tables xfs libcrc32c sd_mod igb ata_generic ptp pata_acpi pps_core mptsas ata_piix scsi_transport_sas i2c_algo_bit libata mptscsih i2c_core serio_raw crc32c_intel bnx2 mptbase dca dm_mirror dm_region_hash dm_log dm_mod
> [ 168.805983] CPU: 15 PID: 10369 Comm: mmap1 Not tainted 4.11.0-rc2-327.28.3.53.x86_64+ #345
> [ 168.814202] Hardware name: Huawei Technologies Co., Ltd. Tecal RH2285 /BC11BTSA , BIOS CTSAV036 04/27/2011
> [ 168.825704] task: ffff8806207d5200 task.stack: ffffc9000c340000
> [ 168.831592] RIP: 0033:0x7f3e622c5360
> [ 168.835147] RSP: 002b:00007ffe2bb7a098 EFLAGS: 00010203
> [ 168.840344] RAX: 00007ffe2bb7a0c0 RBX: 0000000000000000 RCX: 00007f3e6275a000
> [ 168.847439] RDX: 00007f3e622c5360 RSI: 00007f3e6275a000 RDI: 00007ffe2bb7a0c0
> [ 168.854535] RBP: 00007ffe2bb7a4e0 R08: 00007f3e621c3d58 R09: 000000000000002d
> [ 168.861632] R10: 00007ffe2bb79e20 R11: 00007f3e622fbcb0 R12: 00000000004005d0
> [ 168.868728] R13: 00007ffe2bb7a5c0 R14: 0000000000000000 R15: 0000000000000000
> [ 168.875825] FS: 00007f3e62752740(0000) GS:ffff880627bc0000(0000) knlGS:0000000000000000
> [ 168.883870] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 168.889583] CR2: 00007f3e6275a002 CR3: 0000000622845000 CR4: 00000000000006e0
> [ 168.896680] RIP: 0x7f3e622c5360 RSP: 00007ffe2bb7a098
> [ 168.901713] ---[ end trace ef98fa9f2a01cbc6 ]---
> [ 168.90630 arch/x86/kernel/smp.c:127 native_smp_send_reschedule+0x3f/0x50
> [ 168.935410] Modules linked in: intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd iTCO_wdt glue_helper cryptd sg iTCO_vendor_support i7core_edac edac_core shpchp lpc_ich i2c_i801 pcspkr mfd_core acpi_cpufreq ip_tables xfs libcrc32c sd_mod igb ata_generic ptp pata_acpi pps_core mptsas ata_piix scsi_transport_sas i2c_algo_bit libata mptscsih i2c_core serio_raw crc32c_intel bnx2 mptbase dca dm_mirror dm_region_hash dm_log dm_mod
> [ 168.979686] CPU: 15 PID: 10369 Comm: mmap1 Tainted: G D 4.11.0-rc2-327.28.3.53.x86_64+ #345
> [ 168.989114] Hardware name: Huawei Technologies Co., Ltd. Tecal RH2285 /BC11BTSA , BIOS CTSAV036 04/27/2011
> [ 169.000616] Call Trace:
> [ 169.003049] <IRQ>
> [ 169.005050] dump_stack+0x63/0x84
> [ 169.008348] __warn+0xd1/0xf0
> [ 169.011297] warn_slowpath_null+0x1d/0x20
> [ 169.015282] native_smp_send_reschedule+0x3f/0x50
> [ 169.019961] resched_curr+0xa1/0xc0
> [ 169.023428] check_preempt_curr+0x70/0x90
> [ 169.027415] ttwu_do_wakeup+0x1e/0x160
> [ 169.031142] ttwu_do_activate+0x77/0x80
> [ 169.034956] try_to_wake_up+0x1c3/0x430
> [ 169.038771] default_wake_function+0x12/0x20
> [ 169.043019] __wake_up_common+0x55/0x90
> [ 169.046833] __wake_up_locked+0x13/0x20
> [ 169.050649] ep_poll_callback+0xbb/0x240
> [ 169.054550] __wake_up_common+0x55/0x90
> [ 169.058363] __wake_up+0x39/0x50
> [ 169.061574] wake_up_klogd_work_func+0x40/0x60
> [ 169.065994] irq_work_run_list+0x4d/0x70
> [ 169.069895] irq_work_tick+0x40/0x50
> [ 169.073452] update_process_times+0x42/0x60
> [ 169.077612] tick_periodic+0x2b/0x80
> [ 169.081166] tick_handle_periodic+0x25/0x70
> [ 169.085326] local_apic_timer_interrupt+0x35/0x60
> [ 169.090004] smp_apic_timer_interrupt+0x38/0x50
> [ 169.094507] apic_timer_interrupt+0x93/0xa0
> [ 169.098667] RIP: 0010:panic+0x1f5/0x239
> [ 169.102480] RSP: 0000:ffffc9000c343dd8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
> [ 169.110010] RAX: 0000000000000034 RBX: 0000000000000000 RCX: 0000000000000006
> [ 169.117106] RDX: 0000000000000000 RSI: 0000000000000086 RDI: ffff880627bcdfe0
> [ 169.124201] RBP: ffffc9000c343e48 R08: 00000000fffffffe R09: 0000000000000395
> [ 169.131298] R10: 0000000000000005 R11: 0000000000000394 R12: ffffffff81a0c475
> [ 169.138395] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000d
> [ 169.145491] </IRQ>
> [ 169.147578] ? panic+0x1f1/0x239
> [ 169.150789] oops_end+0xb8/0xd0
> [ 169.153910] pgtable_bad+0x8a/0x95
> [ 169.157294] __do_page_fault+0x3aa/0x4a0
> [ 169.161194] do_page_fault+0x30/0x80
> [ 169.164750] ? do_syscall_64+0x175/0x180
> [ 169.168649] page_fault+0x28/0x30
>
> the following case can reproduce the issue.
>
> int mem_fd = 0;
> char rw_buf[1024];
> unsigned char * map_base_s;
> unsigned long show_addr = 0x100000000000;
> unsigned long show_len = 0x10;
>
> if(argc !=2 )
> {
> printf( "%s show_addr\n", argv[0] );
> return 0;
> }
> else
> {
> char *stop;
> show_addr = strtoul( argv[1], &stop, 0 );
> printf("show_addr= 0x%lu\n", show_addr );
> }
>
> mem_fd = open(DEV_NAME, O_RDONLY);
> if (mem_fd == -1)
> {
> printf("open %s failed.", DEV_NAME);
> return 0;
> }
>
> map_base_s = mmap(NULL, show_len, PROT_READ, MAP_SHARED, mem_fd, show_addr);
> if ((long)map_base_s == -1)
> {
> printf("input address map to user space fail!\n");
> return 0;
> }
> else
> {
> printf("mmap successfull!\n");
> }
>
> memcpy( rw_buf, map_base_s, show_len );
>
> The pgoff is enough large, it exceed the size of the real memory.
> and the mmap can return the success.
>
> I fix it by checking the conditions. it can make it suitable for
> the mapped and use.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> drivers/char/mem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> index 7e4a9d1..3a765e02 100644
> --- a/drivers/char/mem.c
> +++ b/drivers/char/mem.c
> @@ -55,7 +55,7 @@ static inline int valid_phys_addr_range(phys_addr_t addr, size_t count)
>
> static inline int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
> {
> - return 1;
> + return (pfn << PAGE_SHIFT) + size <= __pa(high_memory);
> }
> #endif
>
I suppose you are correct that there should be some sanity checking on the
size used for the mmap(). Are you using the default size in your test
program or are you passing it a different size to induce the panic?
There's also the issue of architectures that override this function, such
as on sh that simply returns 1, so I think that would need to be addressed
as well.
Let's add a few people to the cc.
--
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: avoid thrashing anon lru when free + file is low
From: David Rientjes @ 2017-05-02 20:41 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Minchan Kim, Johannes Weiner, Mel Gorman,
linux-kernel, linux-mm
In-Reply-To: <20170502080246.GD14593@dhcp22.suse.cz>
On Tue, 2 May 2017, Michal Hocko wrote:
> I have already asked and my questions were ignored. So let me ask again
> and hopefuly not get ignored this time. So Why do we need a different
> criterion on anon pages than file pages?
The preference in get_scan_count() as already implemented is to reclaim
from file pages if there is enough memory on the inactive list to reclaim.
That is unchanged with this patch.
> I do agree that blindly
> scanning anon pages when file pages are low is very suboptimal but this
> adds yet another heuristic without _any_ numbers. Why cannot we simply
> treat anon and file pages equally? Something like the following
>
> if (pgdatfile + pgdatanon + pgdatfree > 2*total_high_wmark) {
> scan_balance = SCAN_FILE;
> if (pgdatfile < pgdatanon)
> scan_balance = SCAN_ANON;
> goto out;
> }
>
This would be substantially worse than the current code because it
thrashes the anon lru when anon out numbers file pages rather than at the
point we fall under the high watermarks for all eligible zones. If you
tested your suggestion, you could see gigabytes of memory left untouched
on the file lru. Anonymous memory is more probable to be part of the
working set.
> Also it would help to describe the workload which can trigger this
> behavior so that we can compare numbers before and after this patch.
Any workload that fills system RAM with anonymous memory that cannot be
reclaimed will thrash the anon lru without this patch.
--
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 man-pages 0/5] {ioctl_}userfaultfd.2: yet another update
From: Michael Kerrisk (man-pages) @ 2017-05-02 20:28 UTC (permalink / raw)
To: Mike Rapoport
Cc: mtk.manpages, Andrea Arcangeli, linux-kernel, linux-mm, linux-man
In-Reply-To: <20170502094836.GD5910@rapoport-lnx>
On 05/02/2017 11:48 AM, Mike Rapoport wrote:
> On Mon, May 01, 2017 at 08:34:07PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Mike,
>>
>> On 05/01/2017 07:43 AM, Mike Rapoport wrote:
>>> Hi Michael,
>>>
>>> These updates pretty much complete the coverage of 4.11 additions, IMHO.
>>
>> Thanks for this, but we still await input from Andrea
>> on various points.
>>
>>> Mike Rapoport (5):
>>> ioctl_userfaultfd.2: update description of shared memory areas
>>> ioctl_userfaultfd.2: UFFDIO_COPY: add ENOENT and ENOSPC description
>>> ioctl_userfaultfd.2: add BUGS section
>>> userfaultfd.2: add note about asynchronios events delivery
>>> userfaultfd.2: update VERSIONS section with 4.11 chanegs
>>>
>>> man2/ioctl_userfaultfd.2 | 35 +++++++++++++++++++++++++++++++++--
>>> man2/userfaultfd.2 | 15 +++++++++++++++
>>> 2 files changed, 48 insertions(+), 2 deletions(-)
>>
>> I've applied all of the above, and done some light editing.
>>
>> Could you please check my changes in the following commits:
>>
>> 5191c68806c8ac73fdc89586cde434d2766abb5c
>> 265225c1e2311ae26ead116e6c8d2cedd46144fa
>
> Both are Ok
> Reviewed-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Thanks for checking, Mike.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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 man-pages 4/5] userfaultfd.2: add note about asynchronios events delivery
From: Michael Kerrisk (man-pages) @ 2017-05-02 20:27 UTC (permalink / raw)
To: Mike Rapoport
Cc: mtk.manpages, Andrea Arcangeli, linux-kernel, linux-mm, linux-man
In-Reply-To: <20170502094654.GC5910@rapoport-lnx>
On 05/02/2017 11:46 AM, Mike Rapoport wrote:
> On Mon, May 01, 2017 at 08:33:45PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Mike,
>>
>> On 05/01/2017 07:43 AM, Mike Rapoport wrote:
>>> Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
>>
>> Thanks. Applied. One question below.
>>
>>> ---
>>> man2/userfaultfd.2 | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
>>> index 8b89162..f177bba 100644
>>> --- a/man2/userfaultfd.2
>>> +++ b/man2/userfaultfd.2
>>> @@ -112,6 +112,18 @@ created for the child process,
>>> which allows userfaultfd monitor to perform user-space paging
>>> for the child process.
>>>
>>> +Unlike page faults which have to be synchronous and require
>>> +explicit or implicit wakeup,
>>> +all other events are delivered asynchronously and
>>> +the non-cooperative process resumes execution as
>>> +soon as manager executes
>>> +.BR read(2).
>>> +The userfaultfd manager should carefully synchronize calls
>>> +to UFFDIO_COPY with the events processing.
>>> +
>>> +The current asynchronous model of the event delivery is optimal for
>>> +single threaded non-cooperative userfaultfd manager implementations.
>>
>> The preceding paragraph feels incomplete. It seems like you want to make
>> a point with that last sentence, but the point is not explicit. What's
>> missing?
>
> I've copied both from Documentation/vm/userfaulftfd.txt, and there we also
> talk about possibility of addition of synchronous events delivery and
> that makes the paragraph above to seem crippled :)
> The major point here is that current events delivery model could be
> problematic for multi-threaded monitor. I even suspect that it would be
> impossible to ensure synchronization between page faults and non-page
> fault events in multi-threaded monitor.
Okay -- thanks for the info. I've noted it, but won't make changes
any changes to the page for now.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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 man-pages 1/5] ioctl_userfaultfd.2: update description of shared memory areas
From: Michael Kerrisk (man-pages) @ 2017-05-02 20:23 UTC (permalink / raw)
To: Mike Rapoport
Cc: mtk.manpages, Andrea Arcangeli, linux-kernel, linux-mm, linux-man
In-Reply-To: <20170502093110.GA5910@rapoport-lnx>
On 05/02/2017 11:31 AM, Mike Rapoport wrote:
> On Mon, May 01, 2017 at 08:33:31PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hello Mike,
>>
>> I've applied this patch, but have a question.
>>
>> On 05/01/2017 07:43 AM, Mike Rapoport wrote:
>>> Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
>>> ---
>>> man2/ioctl_userfaultfd.2 | 13 +++++++++++--
>>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2
>>> index 889feb9..6edd396 100644
>>> --- a/man2/ioctl_userfaultfd.2
>>> +++ b/man2/ioctl_userfaultfd.2
>>> @@ -181,8 +181,17 @@ virtual memory areas
>>> .TP
>>> .B UFFD_FEATURE_MISSING_SHMEM
>>> If this feature bit is set,
>>> -the kernel supports registering userfaultfd ranges on tmpfs
>>> -virtual memory areas
>>> +the kernel supports registering userfaultfd ranges on shared memory areas.
>>> +This includes all kernel shared memory APIs:
>>> +System V shared memory,
>>> +tmpfs,
>>> +/dev/zero,
>>> +.BR mmap(2)
>>> +with
>>> +.I MAP_SHARED
>>> +flag set,
>>> +.BR memfd_create (2),
>>> +etc.
>>>
>>> The returned
>>> .I ioctls
>>
>> Does the change in this patch represent a change that occurred in
>> Linux 4.11? If so, I think this needs to be said explicitly in the text.
>
> The patch only extends the description of UFFD_FEATURE_MISSING_SHMEM. The
> feature is indeed available from 4.11, but that is said a few lives above
> (line 136 in ioctl_userfaultfd.2)
Okay -- thanks for the clarification.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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 man-pages 1/2] userfaultfd.2: start documenting non-cooperative events
From: Michael Kerrisk (man-pages) @ 2017-05-02 20:19 UTC (permalink / raw)
To: Mike Rapoport
Cc: mtk.manpages, Andrea Arcangeli, linux-kernel, linux-mm, linux-man
In-Reply-To: <20170502092255.GA3022@rapoport-lnx>
On 05/02/2017 11:22 AM, Mike Rapoport wrote:
> On Mon, May 01, 2017 at 08:34:16PM +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Mike,
>>
>> On 04/28/2017 11:45 AM, Mike Rapoprt wrote:
>>>
>>>
>>> On April 27, 2017 8:26:16 PM GMT+03:00, "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> wrote:
>>>> Hi Mike,
>>>>
>>>> I've applied this, but have some questions/points I think
>>>> further clarification.
>>>>
>>>> On 04/27/2017 04:14 PM, Mike Rapoport wrote:
>>>>> Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
>>>>> ---
>>>>> man2/userfaultfd.2 | 135
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++---
>>>>> 1 file changed, 128 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
>>>>> index cfea5cb..44af3e4 100644
>>>>> --- a/man2/userfaultfd.2
>>>>> +++ b/man2/userfaultfd.2
>>>>> @@ -75,7 +75,7 @@ flag in
>>>>> .PP
>>>>> When the last file descriptor referring to a userfaultfd object is
>>>> closed,
>>>>> all memory ranges that were registered with the object are
>>>> unregistered
>>>>> -and unread page-fault events are flushed.
>>>>> +and unread events are flushed.
>>>>> .\"
>>>>> .SS Usage
>>>>> The userfaultfd mechanism is designed to allow a thread in a
>>>> multithreaded
>>>>> @@ -99,6 +99,20 @@ In such non-cooperative mode,
>>>>> the process that monitors userfaultfd and handles page faults
>>>>> needs to be aware of the changes in the virtual memory layout
>>>>> of the faulting process to avoid memory corruption.
>>>>> +
>>>>> +Starting from Linux 4.11,
>>>>> +userfaultfd may notify the fault-handling threads about changes
>>>>> +in the virtual memory layout of the faulting process.
>>>>> +In addition, if the faulting process invokes
>>>>> +.BR fork (2)
>>>>> +system call,
>>>>> +the userfaultfd objects associated with the parent may be duplicated
>>>>> +into the child process and the userfaultfd monitor will be notified
>>>>> +about the file descriptor associated with the userfault objects
>>>>
>>>> What does "notified about the file descriptor" mean?
>>>
>>> Well, seems that I've made this one really awkward :)
>>> When the monitored process forks, all the userfault objects
>>> associateda?? with it are duplicated into the child process. For each
>>> duplicated object, userfault generates event of type UFFD_EVENT_FORK
>>> and the uffdio_msg for this event contains the file descriptor that
>>> should be used to manipulate the duplicated userfault object.
>>> Hope this clarifies.
>>
>> Yes, it's clearer now.
>>
>> Mostly what was needed here was a forward reference that mentions
>> UFFD_EVENT_FORK explicitly. I added that, and also enhanced the
>> text on UFFD_EVENT_FORK a little.
>>
>> Also, it's not just fork(2) for which UFFD_EVENT_FORK is generated,
>> right? It can also be a clone(2) cal that does not specify
>> CLONE_VM, right?
>
> Yes.
>
>> Could you review my changes in commit 522ab2ff6fc9010432a
>> to make sure they are okay.
>
> Yes, thats correct and with your updates the text is much clearer. Thanks.
Thanks for checking!
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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
* WARNING: CPU: 2 PID: 23409 at mm/filemap.c:260 __delete_from_page_cache+0x5fc/0x610
From: Dave Jones @ 2017-05-02 20:13 UTC (permalink / raw)
To: linux-mm; +Cc: Linux Kernel
Just hit this on Linus tree pulled this afternoon.
WARNING: CPU: 2 PID: 23409 at mm/filemap.c:260 __delete_from_page_cache+0x5fc/0x610
CPU: 2 PID: 23409 Comm: trinity-c1 Not tainted 4.11.0-think+ #4
Call Trace:
dump_stack+0x68/0x93
__warn+0xcb/0xf0
warn_slowpath_null+0x1d/0x20
__delete_from_page_cache+0x5fc/0x610
delete_from_page_cache+0x57/0x150
truncate_inode_page+0x9f/0x140
shmem_undo_range+0x4c5/0xcd0
shmem_truncate_range+0x16/0x40
shmem_fallocate+0x22a/0x610
vfs_fallocate+0x135/0x250
SyS_madvise+0x211/0xa90
? get_lock_stats+0x19/0x50
do_syscall_64+0x66/0x1d0
? do_syscall_64+0x66/0x1d0
entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x7f596e520099
RSP: 002b:00007fff1b76d928 EFLAGS: 00000246
ORIG_RAX: 000000000000001c
RAX: ffffffffffffffda RBX: 000000000000001c RCX: 00007f596e520099
RDX: 0000000000000009 RSI: 00000000000fc000 RDI: 00007f596c88b000
RBP: 00007fff1b76d9d0 R08: 0000000000001d1d R09: 0000c1c1c1c1c1c1
R10: 759e2c3076d8be38 R11: 0000000000000246 R12: 0000000000000002
R13: 00007f596ebe8048 R14: 00007f596ebf6ad8 R15: 00007f596ebe8000
260 if (WARN_ON_ONCE(PageDirty(page)))
261 account_page_cleaned(page, mapping, inode_to_wb(mapping->host));
--
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 1/2] mm: Uncharge poisoned pages
From: Michal Hocko @ 2017-05-02 18:55 UTC (permalink / raw)
To: Andi Kleen, Johannes Weiner
Cc: Laurent Dufour, Naoya Horiguchi, linux-kernel, linux-mm, akpm,
Vladimir Davydov
In-Reply-To: <c8ce6056-e89b-7470-c37a-85ab5bc7a5b2@linux.vnet.ibm.com>
On Tue 02-05-17 16:59:30, Laurent Dufour wrote:
> On 28/04/2017 15:48, Michal Hocko wrote:
[...]
> > This is getting quite hairy. What is the expected page count of the
> > hwpoison page?
OK, so from the quick check of the hwpoison code it seems that the ref
count will be > 1 (from get_hwpoison_page).
> > I guess we would need to update the VM_BUG_ON in the
> > memcg uncharge code to ignore the page count of hwpoison pages if it can
> > be arbitrary.
>
> Based on the experiment I did, page count == 2 when isolate_lru_page()
> succeeds, even in the case of a poisoned page.
that would make some sense to me. The page should have been already
unmapped therefore but memory_failure increases the ref count and 1 is
for isolate_lru_page().
> In my case I think this
> is because the page is still used by the process which is calling madvise().
>
> I'm wondering if I'm looking at the right place. May be the poisoned
> page should remain attach to the memory_cgroup until no one is using it.
> In that case this means that something should be done when the page is
> off-lined... I've to dig further here.
No, AFAIU the page will not drop the reference count down to 0 in most
cases. Maybe there are some scenarios where this can happen but I would
expect that the poisoned page will be mapped and in use most of the time
and won't drop down 0. And then we should really uncharge it because it
will pin the memcg and make it unfreeable which doesn't seem to be what
we want. So does the following work reasonable? Andi, Johannes, what do
you think? I cannot say I would be really comfortable touching hwpoison
code as I really do not understand the workflow. Maybe we want to move
this uncharge down to memory_failure() right before we report success?
---
^ permalink raw reply
* Re: [RFC 0/4] RFC - Coherent Device Memory (Not for inclusion)
From: John Hubbard @ 2017-05-02 17:50 UTC (permalink / raw)
To: Balbir Singh, linux-mm, akpm
Cc: khandual, benh, aneesh.kumar, paulmck, srikar, haren, jglisse,
mgorman, mhocko, arbab, vbabka, cl
In-Reply-To: <1493709804.15044.9.camel@gmail.com>
On 05/02/2017 12:23 AM, Balbir Singh wrote:
> On Mon, 2017-05-01 at 22:47 -0700, John Hubbard wrote:
>>
>> On 05/01/2017 06:29 PM, Balbir Singh wrote:
>>> On Mon, 2017-05-01 at 13:41 -0700, John Hubbard wrote:
>>>> On 04/19/2017 12:52 AM, Balbir Singh wrote:
[...]
>>> 1. Enable hotplug of CDM nodes
>>> 2. Isolation of CDM memory
>>> 3. Migration to/from CDM memory
>>> 4. Performance enhancements for migration
>>>
>>
>> So, there is a little more than the above required, which is why I made that short
>> list. I'm in particular concerned about the various system calls that userspace can
>> make to control NUMA memory, and the device drivers will need notification (probably
>> mmu_notifiers, I guess), and once they get notification, in many cases they'll need
>> some way to deal with reverse mapping.
>
> Are you suggesting that the system calls user space should be audited to
> check if they should be used with a CDM device? I would
> think a whole lot of this should be transparent to user space, unless it opts
> in to using CDM and explictly wants to allocate and free memory -- the whole
> isolation premise. w.r.t device drivers are you suggesting that the device
> driver needs to know the state of each page -- free/in-use? Reverse mapping
> for migration?
>
Interesting question. No, I was not going that direction (auditing the various system calls...) at
all, actually. Rather, I was expecting that this system to interact as normally as possible with all
of the system calls, and that is what led me to expect that some combination of "device driver +
enhanced NUMA subsystem" would need to do rmap lookups.
Going through and special-casing CDM for various system calls would probably not be well-received,
because it would be an indication of force-fitting this into the NUMA model before it's ready, right?
>>
>> HMM provides all of that support, so it needs to happen here, too.
>>
>>
>>
>>> The RFC here is for (2) above. (3) is handled by HMM and (4) is being discussed
>>> in the community. I think the larger goals are same as HMM, except that we
>>> don't need unaddressable memory, since the memory is cache coherent.
>>>
>>>>
>>>> So, I'd suggest putting together something more complete, so that it can be fairly
>>>> compared against the HMM-for-hardware-coherent-nodes approach.
>>>>
>>>
>>> Since I intend to reuse bits of HMM, I am not sure if I want to repost those
>>> patches as a part of my RFC. I hope my answers make sense, the goal is to
>>> reuse as much of what is available. From a user perspective
>>
>> It's hard to keep track of what the plan is, so explaining exactly what you're doing
>> helps.
>>
>
> Fair enough, I hope I answered the questions?
Yes, thanks.
>>>
>>> 1. We see no new interface being added in either case, the programming model
>>> would differ though
>>> 2. We expect the programming model to be abstracted behind a user space
>>> framework, potentially like CUDA or CXL
>>>
>>>
>>>>
>>>>> Jerome posted HMM-CDM at https://lwn.net/Articles/713035/.
>>>>> The patches do a great deal to enable CDM with HMM, but we
>>>>> still believe that HMM with CDM is not a natural way to
>>>>> represent coherent device memory and the mm will need
>>>>> to be audited and enhanced for it to even work.
>>>>
>>>> That is also true for the CDM approach. Specifically, in order for this to be of any
>>>> use to device drivers, we'll need the following:
>>>>
>>>
>>> Since Reza answered these questions, I'll skip them in this email
>>
>> Yes, but he skipped over the rmap question, which I think is an important one.
>>
>
> If it is for migration, then we are going to rely on changes from HMM-CDM.
> How does HMM deal with the rmap case? I presume it is not required for
> unaddressable memory?
>
> Balbir Singh.
>
That's correct, we don't need rmap access for device drivers in the "pure HMM" case, because the HMM
core handles it.
thanks
john h
--
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: Marcelo Tosatti @ 2017-05-02 17:21 UTC (permalink / raw)
To: Luiz Capitulino, Christoph Lameter
Cc: linux-kernel, linux-mm, Rik van Riel, Linux RT Users, cmetcalf
In-Reply-To: <20170502131527.7532fc2e@redhat.com>
On Tue, May 02, 2017 at 01:15:27PM -0400, Luiz Capitulino wrote:
> On Tue, 2 May 2017 13:52:00 -0300
> Marcelo Tosatti <mtosatti@redhat.com> wrote:
>
> > > I have several questions about the tunables:
> > >
> > > - What does the vmstat_threshold value mean? What are the implications
> > > of changing this value? What's the difference in choosing 1, 2, 3
> > > or 500?
> >
> > Its the maximum value for a vmstat statistics counter to hold. After
> > that value, the statistics are transferred to the global counter:
> >
> > void __mod_node_page_state(struct pglist_data *pgdat, enum node_stat_item item,
> > long delta)
> > {
> > struct per_cpu_nodestat __percpu *pcp = pgdat->per_cpu_nodestats;
> > s8 __percpu *p = pcp->vm_node_stat_diff + item;
> > long x;
> > long t;
> >
> > x = delta + __this_cpu_read(*p);
> >
> > t = __this_cpu_read(pcp->stat_threshold);
> >
> > if (unlikely(x > t || x < -t)) {
> > node_page_state_add(x, pgdat, item);
> > x = 0;
> > }
> > __this_cpu_write(*p, x);
> > }
> > EXPORT_SYMBOL(__mod_node_page_state);
> >
> > BTW, there is a bug there, should change that to:
> >
> > if (unlikely(x >= t || x <= -t)) {
> >
> > Increasing the threshold value does two things:
> > 1) It decreases the number of inter-processor accesses.
> > 2) It increases how much the global counters stay out of
> > sync relative to actual current values.
>
> OK, but I'm mostly concerned with the sysadmin who will have
> to change the tunable. So, I think it's a good idea to improve
> the doc to contain that information.
Yes, how is that:
Index: linux-2.6-git-disable-vmstat-worker/Documentation/vm/vmstat_thresholds.txt
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-git-disable-vmstat-worker/Documentation/vm/vmstat_thresholds.txt 2017-05-02 13:48:45.946840708 -0300
@@ -0,0 +1,78 @@
+Userspace configurable vmstat thresholds
+========================================
+
+This document describes the tunables to control
+per-CPU vmstat threshold and per-CPU vmstat worker
+thread.
+
+/sys/devices/system/cpu/cpuN/vmstat/vmstat_threshold:
+
+This file contains the per-CPU vmstat threshold.
+This value is the maximum that a single per-CPU vmstat statistic
+can accumulate before transferring to the global counters.
+
+A value of 0 indicates that the value is set
+by the in kernel algorithm.
+
+A value different than 0 indicates that particular
+value is used for vmstat_threshold.
+
+/sys/devices/system/cpu/cpuN/vmstat/vmstat_worker:
+
+Enable/disable the per-CPU vmstat worker.
+
+What does the vmstat_threshold value mean? What are the implications
+of changing this value? What's the difference in choosing 1, 2, 3
+or 500?
+====================================================================
+
+Its the maximum value for a vmstat statistics counter to hold. After
+that value, the statistics are transferred to the global counter:
+
+void __mod_node_page_state(struct pglist_data *pgdat, enum node_stat_item item,
+ long delta)
+{
+ struct per_cpu_nodestat __percpu *pcp = pgdat->per_cpu_nodestats;
+ s8 __percpu *p = pcp->vm_node_stat_diff + item;
+ long x;
+ long t;
+
+ x = delta + __this_cpu_read(*p);
+
+ t = __this_cpu_read(pcp->stat_threshold);
+
+ if (unlikely(x > t || x < -t)) {
+ node_page_state_add(x, pgdat, item);
+ x = 0;
+ }
+ __this_cpu_write(*p, x);
+}
+
+Increasing the threshold value does two things:
+ 1) It decreases the number of inter-processor accesses.
+ 2) It increases how much the global counters stay out of
+ sync relative to actual current values.
+
+
+Usage example:
+=============
+
+In a realtime system, the worker thread waking up and executing
+vmstat_update can be an undesired source of latencies.
+
+To avoid the worker thread from waking up, executing vmstat_update
+on cpu 1, for example, perform the following steps:
+
+
+cd /sys/devices/system/cpu/cpu0/vmstat/
+
+# Set vmstat threshold to 1 for cpu1, so that no
+# vmstat statistics are collected in cpu1's per-cpu
+# stats, instead they are immediately transferred
+# to the global counter.
+
+$ echo 1 > vmstat_threshold
+
+# Disable vmstat_update worker for cpu1:
+$ echo 0 > vmstat_worker
+
> > > - If the purpose of having vmstat_threshold is to allow disabling
> > > the vmstat kworker, why can't the kernel pick a value automatically?
> >
> > Because it might be acceptable for the user to accept a small
> > out of syncedness of the global counters in favour of performance
> > (one would have to analyze the situation).
> >
> > Setting vmstat_threshold == 1 means the global counter is always
> > in sync with the page counter state of the pCPU.
>
> IMHO, if vmstat_threshold == 1 is the required setting for
> disabling the vmstat kworker then I'd go with only one tunable
> for now. But that's just a suggestion.
I didnt want to force that on the user because allowing different
tunables covers more cases.
> > > - What are the implications of disabling the vmstat kworker? Will vm
> > > stats still be collected someway or will it be completely off for
> > > the CPU?
> >
> > It will not be necessary to collect vmstats because at every modification
> > of the vm statistics, pCPUs with vmstat_threshold=1 transfer their
> > values to the global counters (that is, there is no queueing of statistics
> > locally to improve performance).
>
> 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).
Christoph?
> > > Also, shouldn't this patch be split into two?
> >
> > First add one sysfs file, then add another sysfs file, you mean?
>
> Yes, one tunable per patch.
Sure.
--
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: Luiz Capitulino @ 2017-05-02 17:15 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: linux-kernel, linux-mm, Rik van Riel, Linux RT Users, cl,
cmetcalf
In-Reply-To: <20170502165159.GA5457@amt.cnet>
On Tue, 2 May 2017 13:52:00 -0300
Marcelo Tosatti <mtosatti@redhat.com> wrote:
> > I have several questions about the tunables:
> >
> > - What does the vmstat_threshold value mean? What are the implications
> > of changing this value? What's the difference in choosing 1, 2, 3
> > or 500?
>
> Its the maximum value for a vmstat statistics counter to hold. After
> that value, the statistics are transferred to the global counter:
>
> void __mod_node_page_state(struct pglist_data *pgdat, enum node_stat_item item,
> long delta)
> {
> struct per_cpu_nodestat __percpu *pcp = pgdat->per_cpu_nodestats;
> s8 __percpu *p = pcp->vm_node_stat_diff + item;
> long x;
> long t;
>
> x = delta + __this_cpu_read(*p);
>
> t = __this_cpu_read(pcp->stat_threshold);
>
> if (unlikely(x > t || x < -t)) {
> node_page_state_add(x, pgdat, item);
> x = 0;
> }
> __this_cpu_write(*p, x);
> }
> EXPORT_SYMBOL(__mod_node_page_state);
>
> BTW, there is a bug there, should change that to:
>
> if (unlikely(x >= t || x <= -t)) {
>
> Increasing the threshold value does two things:
> 1) It decreases the number of inter-processor accesses.
> 2) It increases how much the global counters stay out of
> sync relative to actual current values.
OK, but I'm mostly concerned with the sysadmin who will have
to change the tunable. So, I think it's a good idea to improve
the doc to contain that information.
> > - If the purpose of having vmstat_threshold is to allow disabling
> > the vmstat kworker, why can't the kernel pick a value automatically?
>
> Because it might be acceptable for the user to accept a small
> out of syncedness of the global counters in favour of performance
> (one would have to analyze the situation).
>
> Setting vmstat_threshold == 1 means the global counter is always
> in sync with the page counter state of the pCPU.
IMHO, if vmstat_threshold == 1 is the required setting for
disabling the vmstat kworker then I'd go with only one tunable
for now. But that's just a suggestion.
>
> > - What are the implications of disabling the vmstat kworker? Will vm
> > stats still be collected someway or will it be completely off for
> > the CPU?
>
> It will not be necessary to collect vmstats because at every modification
> of the vm statistics, pCPUs with vmstat_threshold=1 transfer their
> values to the global counters (that is, there is no queueing of statistics
> locally to improve performance).
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).
> > Also, shouldn't this patch be split into two?
>
> First add one sysfs file, then add another sysfs file, you mean?
Yes, one tunable per patch.
--
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: Marcelo Tosatti @ 2017-05-02 16:52 UTC (permalink / raw)
To: Luiz Capitulino
Cc: linux-kernel, linux-mm, Rik van Riel, Linux RT Users, cl,
cmetcalf
In-Reply-To: <20170502102836.4a4d34ba@redhat.com>
On Tue, May 02, 2017 at 10:28:36AM -0400, Luiz Capitulino wrote:
> On Tue, 25 Apr 2017 10:57:19 -0300
> Marcelo Tosatti <mtosatti@redhat.com> wrote:
>
> > The per-CPU vmstat worker is a problem on -RT workloads (because
> > ideally the CPU is entirely reserved for the -RT app, without
> > interference). The worker transfers accumulated per-CPU
> > vmstat counters to global counters.
>
> This is a problem for non-RT too. Any task pinned to an isolated
> CPU that doesn't want to be ever interrupted will be interrupted
> by the vmstat kworker.
>
> > To resolve the problem, create two tunables:
> >
> > * Userspace configurable per-CPU vmstat threshold: by default the
> > VM code calculates the size of the per-CPU vmstat arrays. This
> > tunable allows userspace to configure the values.
> >
> > * Userspace configurable per-CPU vmstat worker: allow disabling
> > the per-CPU vmstat worker.
>
> I have several questions about the tunables:
>
> - What does the vmstat_threshold value mean? What are the implications
> of changing this value? What's the difference in choosing 1, 2, 3
> or 500?
Its the maximum value for a vmstat statistics counter to hold. After
that value, the statistics are transferred to the global counter:
void __mod_node_page_state(struct pglist_data *pgdat, enum node_stat_item item,
long delta)
{
struct per_cpu_nodestat __percpu *pcp = pgdat->per_cpu_nodestats;
s8 __percpu *p = pcp->vm_node_stat_diff + item;
long x;
long t;
x = delta + __this_cpu_read(*p);
t = __this_cpu_read(pcp->stat_threshold);
if (unlikely(x > t || x < -t)) {
node_page_state_add(x, pgdat, item);
x = 0;
}
__this_cpu_write(*p, x);
}
EXPORT_SYMBOL(__mod_node_page_state);
BTW, there is a bug there, should change that to:
if (unlikely(x >= t || x <= -t)) {
Increasing the threshold value does two things:
1) It decreases the number of inter-processor accesses.
2) It increases how much the global counters stay out of
sync relative to actual current values.
> - If the purpose of having vmstat_threshold is to allow disabling
> the vmstat kworker, why can't the kernel pick a value automatically?
Because it might be acceptable for the user to accept a small
out of syncedness of the global counters in favour of performance
(one would have to analyze the situation).
Setting vmstat_threshold == 1 means the global counter is always
in sync with the page counter state of the pCPU.
> - What are the implications of disabling the vmstat kworker? Will vm
> stats still be collected someway or will it be completely off for
> the CPU?
It will not be necessary to collect vmstats because at every modification
of the vm statistics, pCPUs with vmstat_threshold=1 transfer their
values to the global counters (that is, there is no queueing of statistics
locally to improve performance).
> Also, shouldn't this patch be split into two?
First add one sysfs file, then add another sysfs file, you mean?
--
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: post-init-read-only protection for data allocated dynamically
From: Michal Hocko @ 2017-05-02 16:47 UTC (permalink / raw)
To: Igor Stoppa; +Cc: linux-mm
In-Reply-To: <20170428074540.GB9399@dhcp22.suse.cz>
[You have already started new thread with the way how to introduce a new
zone and that might turn out to be useful but I think it is much more
important to understand requirements for the usecase you have in mind as
first]
On Fri 28-04-17 09:45:40, Michal Hocko wrote:
> On Fri 21-04-17 11:30:04, Igor Stoppa wrote:
> > Hello,
> >
> > I am looking for a mechanism to protect the kernel data which is allocated
> > dynamically during system initialization and is later-on accessed only for
> > reads.
> >
> > The functionality would be, in spirit, like the __read_only modifier, which
> > can be used to mark static data as read-only, in the post-init phase. Only,
> > it would apply to dynamically allocated data.
> >
> > I couldn't find any such feature (did I miss it?), so I started looking at
> > what could be the best way to introduce it.
> >
> > The static post-init write protection is achieved by placing all the data
> > into a page-aligned segment and then protecting the page from writes, using
> > the MMU, once the data is in its final state.
> >
> > In my case, as example, I want to protect the SE Linux policy database,
> > after the set of policy has been loaded from file.
> > SE Linux uses fairly complex data structures, which are allocated
> > dynamically, depending on what rules/policy are loaded into it.
> >
> > If I knew upfront, roughly, which sizes will be requested and how many
> > requests will happen, for each size, I could use multiple pools of objects.
> > However, I cannot assume upfront to know these parameters, because it's very
> > likely that the set of policies & rules will evolve.
> >
> > I would also like to extend the write protection to other data structures,
> > which means I would probably end up writing another memory allocator, if I
> > started to generate on-demand object pools.
>
> What is the expected life time of those objects? Are they ever freed? If
> yes are they freed at once or some might outlive others?
>
> > The alternative I'm considering is that, if I were to add a new memory zone
> > (let's call it LOCKABLE), I could piggy back on the existing infrastructure
> > for memory allocation.
>
> No, please no new memory zones! This doesn't look like a good fit
> anyway. I believe you need an allocator on top of the page allocator
> which manages kernel page tables on top of pools of pages. You really do
> not care about where the page is placed physically. I am not sure how
> much you can reuse from the SL.B object management because that highly
> depends on the life time of objects.
--
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 RFC] hugetlbfs 'noautofill' mount option
From: Prakash Sangappa @ 2017-05-02 16:07 UTC (permalink / raw)
To: Anshuman Khandual, linux-kernel, linux-mm
In-Reply-To: <06c4eb97-1545-7958-7694-3645d317666b@linux.vnet.ibm.com>
On 5/2/17 3:53 AM, Anshuman Khandual wrote:
> On 05/01/2017 11:30 PM, Prakash Sangappa wrote:
>> Some applications like a database use hugetblfs for performance
>> reasons. Files on hugetlbfs filesystem are created and huge pages
>> allocated using fallocate() API. Pages are deallocated/freed using
>> fallocate() hole punching support that has been added to hugetlbfs.
>> These files are mmapped and accessed by many processes as shared memory.
>> Such applications keep track of which offsets in the hugetlbfs file have
>> pages allocated.
>>
>> Any access to mapped address over holes in the file, which can occur due
> s/mapped/unmapped/ ^ ?
It is 'mapped' address.
>
>> to bugs in the application, is considered invalid and expect the process
>> to simply receive a SIGBUS. However, currently when a hole in the file is
>> accessed via the mapped address, kernel/mm attempts to automatically
>> allocate a page at page fault time, resulting in implicitly filling the
>> hole
> But this is expected when you try to control the file allocation from
> a mapped address. Any changes while walking past or writing the range
> in the memory mapped should reflect exactly in the file on the disk.
> Why its not a valid behavior ?
Sure, that is a valid behavior. However, hugetlbfs is a pesudo filesystem
and the purpose is for applications to use hugepage memory. The contents
of these filesystem are not backed by disk nor are they swapped out.
The proposed new behavior is only applicable for hugetlbfs filesystem
mounted
with the new 'noautofill' mount option. The file's page allocation/free
are managed
using the 'fallocate()' API.
For hugetlbfs filesystems mounted without this option, there is no
change in behavior.
>> in the file. This may not be the desired behavior for applications like the
>> database that want to explicitly manage page allocations of hugetlbfs
>> files.
>>
>> This patch adds a new hugetlbfs mount option 'noautofill', to indicate that
>> pages should not be allocated at page fault time when accessed thru mmapped
>> address.
> When the page should be allocated for mapping ?
The application would allocate/free file pages using the fallocate() API.
--
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] vmscan: scan pages until it founds eligible pages
From: Michal Hocko @ 2017-05-02 15:14 UTC (permalink / raw)
To: Minchan Kim
Cc: Andrew Morton, Johannes Weiner, Mel Gorman, kernel-team,
linux-kernel, linux-mm
In-Reply-To: <20170502145150.GA19011@bgram>
On Tue 02-05-17 23:51:50, Minchan Kim wrote:
> Hi Michal,
>
> On Tue, May 02, 2017 at 09:54:32AM +0200, Michal Hocko wrote:
> > On Tue 02-05-17 14:14:52, Minchan Kim wrote:
> > > Oops, forgot to add lkml and linux-mm.
> > > Sorry for that.
> > > Send it again.
> > >
> > > >From 8ddf1c8aa15baf085bc6e8c62ce705459d57ea4c Mon Sep 17 00:00:00 2001
> > > From: Minchan Kim <minchan@kernel.org>
> > > Date: Tue, 2 May 2017 12:34:05 +0900
> > > Subject: [PATCH] vmscan: scan pages until it founds eligible pages
> > >
> > > On Tue, May 02, 2017 at 01:40:38PM +0900, Minchan Kim wrote:
> > > There are premature OOM happening. Although there are a ton of free
> > > swap and anonymous LRU list of elgible zones, OOM happened.
> > >
> > > 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.
> >
> > I am not really sure I understand the problem you are facing. Could you
> > be more specific please? What is your configuration etc...
>
> Sure, KVM guest on x86_64, It has 2G memory and 1G swap and configured
> movablecore=1G to simulate highmem zone.
> Workload is a process consumes 2.2G memory and then random touch the
> address space so it makes lots of swap in/out.
>
> >
> > > balloon invoked oom-killer: gfp_mask=0x17080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), nodemask=(null), order=0, oom_score_adj=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
> >
> > Hmm DMA32 has sufficient free memory to allow this order-0 request.
> > Inactive anon lru is basically empty. Why do not we rotate a really
> > large active anon list? Isn't this the primary problem?
>
> It's a side effect by skipping page logic in isolate_lru_pages
> I mentioned above in changelog.
>
> The problem is a lot of anonymous memory in movable zone(ie, highmem)
> and non-small memory in DMA32 zone.
Such a configuration is questionable on its own. But let't keep this
part alone.
> In heavy memory pressure,
> requesting a page in GFP_KERNEL triggers reclaim. VM knows inactive list
> is low so it tries to deactivate pages. For it, first of all, it tries
> to isolate pages from active list but there are lots of anonymous pages
> from movable zone so skipping logic in isolate_lru_pages works. With
> the result, isolate_lru_pages cannot isolate any eligible pages so
> reclaim trial is effectively void. It continues to meet OOM.
But skipped pages should be rotated and we should eventually hit pages
from the right zone(s). Moreover we should scan the full LRU at priority
0 so why exactly we hit the OOM killer?
Anyway [1] has changed this behavior. Are you seeing the issue with this
patch dropped?
[1] http://www.ozlabs.org/~akpm/mmotm/broken-out/revert-mm-vmscan-account-for-skipped-pages-as-a-partial-scan.patch
--
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