From: Gerhard Wiesinger <lists@wiesinger.com>
To: Minchan Kim <minchan@kernel.org>, Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Still OOM problems with 4.9er/4.10er kernels
Date: Thu, 16 Mar 2017 07:38:08 +0100 [thread overview]
Message-ID: <feebcc24-2863-1bdf-e586-1ac9648b35ba@wiesinger.com> (raw)
In-Reply-To: <20170302071721.GA32632@bbox>
On 02.03.2017 08:17, Minchan Kim wrote:
> Hi Michal,
>
> On Tue, Feb 28, 2017 at 09:12:24AM +0100, Michal Hocko wrote:
>> On Tue 28-02-17 14:17:23, Minchan Kim wrote:
>>> On Mon, Feb 27, 2017 at 10:44:49AM +0100, Michal Hocko wrote:
>>>> On Mon 27-02-17 18:02:36, Minchan Kim wrote:
>>>> [...]
>>>>> >From 9779a1c5d32e2edb64da5cdfcd6f9737b94a247a Mon Sep 17 00:00:00 2001
>>>>> From: Minchan Kim <minchan@kernel.org>
>>>>> Date: Mon, 27 Feb 2017 17:39:06 +0900
>>>>> Subject: [PATCH] mm: use up highatomic before OOM kill
>>>>>
>>>>> Not-Yet-Signed-off-by: Minchan Kim <minchan@kernel.org>
>>>>> ---
>>>>> mm/page_alloc.c | 14 ++++----------
>>>>> 1 file changed, 4 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>>>> index 614cd0397ce3..e073cca4969e 100644
>>>>> --- a/mm/page_alloc.c
>>>>> +++ b/mm/page_alloc.c
>>>>> @@ -3549,16 +3549,6 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order,
>>>>> *no_progress_loops = 0;
>>>>> else
>>>>> (*no_progress_loops)++;
>>>>> -
>>>>> - /*
>>>>> - * Make sure we converge to OOM if we cannot make any progress
>>>>> - * several times in the row.
>>>>> - */
>>>>> - if (*no_progress_loops > MAX_RECLAIM_RETRIES) {
>>>>> - /* Before OOM, exhaust highatomic_reserve */
>>>>> - return unreserve_highatomic_pageblock(ac, true);
>>>>> - }
>>>>> -
>>>>> /*
>>>>> * Keep reclaiming pages while there is a chance this will lead
>>>>> * somewhere. If none of the target zones can satisfy our allocation
>>>>> @@ -3821,6 +3811,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>>>>> if (read_mems_allowed_retry(cpuset_mems_cookie))
>>>>> goto retry_cpuset;
>>>>>
>>>>> + /* Before OOM, exhaust highatomic_reserve */
>>>>> + if (unreserve_highatomic_pageblock(ac, true))
>>>>> + goto retry;
>>>>> +
>>>> OK, this can help for higher order requests when we do not exhaust all
>>>> the retries and fail on compaction but I fail to see how can this help
>>>> for order-0 requets which was what happened in this case. I am not
>>>> saying this is wrong, though.
>>> The should_reclaim_retry can return false although no_progress_loop is less
>>> than MAX_RECLAIM_RETRIES unless eligible zones has enough reclaimable pages
>>> by the progress_loop.
>> Yes, sorry I should have been more clear. I was talking about this
>> particular case where we had a lot of reclaimable pages (a lot of
>> anonymous with the swap available).
> This reports shows two problems. Why we see OOM 1) enough *free* pages and
> 2) enough *freeable* pages.
>
> I just pointed out 1) and sent the patch to solve it.
>
> About 2), one of my imaginary scenario is inactive anon list is full of
> pinned pages so VM can unmap them successfully in shrink_page_list but fail
> to free due to increased page refcount. In that case, the page will be added
> to inactive anonymous LRU list again without activating so inactive_list_is_low
> on anonymous LRU is always false. IOW, there is no deactivation from active list.
>
> It's just my picture without no clue. ;-)
With latest kernels (4.11.0-0.rc2.git0.2.fc26.x86_64) I'm having the
issue that swapping is active all the time after some runtime (~1day).
top - 07:30:17 up 1 day, 19:42, 1 user, load average: 13.71, 16.98, 15.36
Tasks: 130 total, 2 running, 128 sleeping, 0 stopped, 0 zombie
%Cpu(s): 15.8 us, 33.5 sy, 0.0 ni, 3.9 id, 34.5 wa, 4.9 hi, 1.0 si,
6.4 st
KiB Mem : 369700 total, 5484 free, 311556 used, 52660 buff/cache
KiB Swap: 2064380 total, 1187684 free, 876696 used. 20340 avail Mem
[root@smtp ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system--
------cpu-----
r b swpd free buff cache si so bi bo in cs us sy
id wa st
3 1 876280 7132 16536 64840 238 226 1027 258 80 97 2 3
83 11 1
0 4 876140 3812 10520 64552 3676 168 11840 1100 2255 2582 7
13 8 70 3
0 3 875372 3628 4024 56160 5424 64 10004 476 2157 2580 2
14 0 83 2
0 4 875560 24056 2208 56296 9032 2180 39928 2388 4111 4549 10
32 0 55 3
2 2 875660 7540 5256 58220 5536 1604 48756 1864 4505 4196 12
23 5 58 3
0 3 875264 3664 2120 57596 2304 116 17904 560 2223 1825 15
15 0 67 3
0 2 875564 3800 588 57856 1340 1068 14780 1184 1390 1364 12
10 0 77 3
1 2 875724 3740 372 53988 3104 928 16884 1068 1560 1527 3
12 0 83 3
0 3 881096 3708 532 52220 4604 5872 21004 6104 2752 2259 7
18 5 67 2
The following commit is included in that version:
commit 710531320af876192d76b2c1f68190a1df941b02
Author: Michal Hocko <mhocko@suse.com>
Date: Wed Feb 22 15:45:58 2017 -0800
mm, vmscan: cleanup lru size claculations
commit fd538803731e50367b7c59ce4ad3454426a3d671 upstream.
But still OOMs:
[157048.030760] clamscan: page allocation stalls for 19405ms, order:0,
mode:0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null)
[157048.031985] clamscan cpuset=/ mems_allowed=0
[157048.031993] CPU: 1 PID: 9597 Comm: clamscan Not tainted
4.11.0-0.rc2.git0.2.fc26.x86_64 #1
[157048.033197] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.9.3 04/01/2014
[157048.034382] Call Trace:
[157048.035532] dump_stack+0x63/0x84
[157048.036735] warn_alloc+0x10c/0x1b0
[157048.037768] __alloc_pages_slowpath+0x93d/0xe60
[157048.038873] ? dd_dispatch_request+0x2b/0x1a0
[157048.041033] ? get_page_from_freelist+0x122/0xbf0
[157048.042435] __alloc_pages_nodemask+0x290/0x2b0
[157048.043662] alloc_pages_vma+0xa0/0x2b0
[157048.044796] __read_swap_cache_async+0x146/0x210
[157048.045841] read_swap_cache_async+0x26/0x60
[157048.046858] swapin_readahead+0x186/0x230
[157048.047854] ? radix_tree_lookup_slot+0x22/0x50
[157048.049006] ? find_get_entry+0x20/0x140
[157048.053109] ? pagecache_get_page+0x2c/0x2e0
[157048.054179] do_swap_page+0x276/0x7b0
[157048.055138] __handle_mm_fault+0x6fd/0x1160
[157048.057571] ? pick_next_task_fair+0x48c/0x560
[157048.058608] handle_mm_fault+0xb3/0x250
[157048.059622] __do_page_fault+0x23f/0x4c0
[157048.068926] trace_do_page_fault+0x41/0x120
[157048.070143] do_async_page_fault+0x51/0xa0
[157048.071254] async_page_fault+0x28/0x30
[157048.072606] RIP: 0033:0x7f78659eb675
[157048.073858] RSP: 002b:00007ffcaba111b8 EFLAGS: 00010202
[157048.075192] RAX: 0000000000000941 RBX: 00007f785957e8d0 RCX:
00007f784e968b48
[157048.076609] RDX: 00007f784f87bce8 RSI: 00007f7851fdb0cb RDI:
00007f7866726000
[157048.077809] RBP: 00007f785957e910 R08: 0000000000040000 R09:
0000000000000000
[157048.078935] R10: ffffffffffffff48 R11: 0000000000000246 R12:
00007f78600c81c0
[157048.080028] R13: 00007f785957e970 R14: 00007f78594ffba8 R15:
0000000003406237
[157048.081827] Mem-Info:
[157048.083005] active_anon:19902 inactive_anon:19920 isolated_anon:383
active_file:816 inactive_file:529 isolated_file:0
unevictable:0 dirty:0 writeback:19 unstable:0
slab_reclaimable:4225 slab_unreclaimable:6483
mapped:942 shmem:3 pagetables:3553 bounce:0
free:944 free_pcp:87 free_cma:0
[157048.089470] Node 0 active_anon:79552kB inactive_anon:79588kB
active_file:3108kB inactive_file:2144kB unevictable:0kB
isolated(anon):1624kB isolated(file):0kB mapped:3612kB dirty:0kB
writeback:76kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp:
12kB writeback_tmp:0kB unstable:0kB pages_scanned:247 all_unreclaimable? no
[157048.092318] Node 0 DMA free:1408kB min:104kB low:128kB high:152kB
active_anon:664kB inactive_anon:3124kB active_file:48kB
inactive_file:40kB unevictable:0kB writepending:0kB present:15992kB
managed:15908kB mlocked:0kB slab_reclaimable:564kB
slab_unreclaimable:2148kB kernel_stack:92kB pagetables:1328kB bounce:0kB
free_pcp:0kB local_pcp:0kB free_cma:0kB
[157048.096008] lowmem_reserve[]: 0 327 327 327 327
[157048.097234] Node 0 DMA32 free:2576kB min:2264kB low:2828kB
high:3392kB active_anon:78844kB inactive_anon:76612kB active_file:2840kB
inactive_file:1896kB unevictable:0kB writepending:76kB present:376688kB
managed:353792kB mlocked:0kB slab_reclaimable:16336kB
slab_unreclaimable:23784kB kernel_stack:2388kB pagetables:12884kB
bounce:0kB free_pcp:644kB local_pcp:312kB free_cma:0kB
[157048.101118] lowmem_reserve[]: 0 0 0 0 0
[157048.102190] Node 0 DMA: 37*4kB (UEH) 12*8kB (H) 13*16kB (H) 10*32kB
(H) 4*64kB (H) 3*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB =
1412kB
[157048.104989] Node 0 DMA32: 79*4kB (UMEH) 199*8kB (UMEH) 18*16kB (UMH)
5*32kB (H) 2*64kB (H) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
= 2484kB
[157048.107789] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
[157048.107790] 2027 total pagecache pages
[157048.109125] 710 pages in swap cache
[157048.115088] Swap cache stats: add 36179491, delete 36179123, find
86964755/101977142
[157048.116934] Free swap = 808064kB
[157048.118466] Total swap = 2064380kB
[157048.122828] 98170 pages RAM
[157048.124039] 0 pages HighMem/MovableOnly
[157048.125051] 5745 pages reserved
[157048.125997] 0 pages cma reserved
[157048.127008] 0 pages hwpoisoned
Thnx.
Ciao,
Gerhard
WARNING: multiple messages have this Message-ID (diff)
From: Gerhard Wiesinger <lists@wiesinger.com>
To: Minchan Kim <minchan@kernel.org>, Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Still OOM problems with 4.9er/4.10er kernels
Date: Thu, 16 Mar 2017 07:38:08 +0100 [thread overview]
Message-ID: <feebcc24-2863-1bdf-e586-1ac9648b35ba@wiesinger.com> (raw)
In-Reply-To: <20170302071721.GA32632@bbox>
On 02.03.2017 08:17, Minchan Kim wrote:
> Hi Michal,
>
> On Tue, Feb 28, 2017 at 09:12:24AM +0100, Michal Hocko wrote:
>> On Tue 28-02-17 14:17:23, Minchan Kim wrote:
>>> On Mon, Feb 27, 2017 at 10:44:49AM +0100, Michal Hocko wrote:
>>>> On Mon 27-02-17 18:02:36, Minchan Kim wrote:
>>>> [...]
>>>>> >From 9779a1c5d32e2edb64da5cdfcd6f9737b94a247a Mon Sep 17 00:00:00 2001
>>>>> From: Minchan Kim <minchan@kernel.org>
>>>>> Date: Mon, 27 Feb 2017 17:39:06 +0900
>>>>> Subject: [PATCH] mm: use up highatomic before OOM kill
>>>>>
>>>>> Not-Yet-Signed-off-by: Minchan Kim <minchan@kernel.org>
>>>>> ---
>>>>> mm/page_alloc.c | 14 ++++----------
>>>>> 1 file changed, 4 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>>>> index 614cd0397ce3..e073cca4969e 100644
>>>>> --- a/mm/page_alloc.c
>>>>> +++ b/mm/page_alloc.c
>>>>> @@ -3549,16 +3549,6 @@ should_reclaim_retry(gfp_t gfp_mask, unsigned order,
>>>>> *no_progress_loops = 0;
>>>>> else
>>>>> (*no_progress_loops)++;
>>>>> -
>>>>> - /*
>>>>> - * Make sure we converge to OOM if we cannot make any progress
>>>>> - * several times in the row.
>>>>> - */
>>>>> - if (*no_progress_loops > MAX_RECLAIM_RETRIES) {
>>>>> - /* Before OOM, exhaust highatomic_reserve */
>>>>> - return unreserve_highatomic_pageblock(ac, true);
>>>>> - }
>>>>> -
>>>>> /*
>>>>> * Keep reclaiming pages while there is a chance this will lead
>>>>> * somewhere. If none of the target zones can satisfy our allocation
>>>>> @@ -3821,6 +3811,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>>>>> if (read_mems_allowed_retry(cpuset_mems_cookie))
>>>>> goto retry_cpuset;
>>>>>
>>>>> + /* Before OOM, exhaust highatomic_reserve */
>>>>> + if (unreserve_highatomic_pageblock(ac, true))
>>>>> + goto retry;
>>>>> +
>>>> OK, this can help for higher order requests when we do not exhaust all
>>>> the retries and fail on compaction but I fail to see how can this help
>>>> for order-0 requets which was what happened in this case. I am not
>>>> saying this is wrong, though.
>>> The should_reclaim_retry can return false although no_progress_loop is less
>>> than MAX_RECLAIM_RETRIES unless eligible zones has enough reclaimable pages
>>> by the progress_loop.
>> Yes, sorry I should have been more clear. I was talking about this
>> particular case where we had a lot of reclaimable pages (a lot of
>> anonymous with the swap available).
> This reports shows two problems. Why we see OOM 1) enough *free* pages and
> 2) enough *freeable* pages.
>
> I just pointed out 1) and sent the patch to solve it.
>
> About 2), one of my imaginary scenario is inactive anon list is full of
> pinned pages so VM can unmap them successfully in shrink_page_list but fail
> to free due to increased page refcount. In that case, the page will be added
> to inactive anonymous LRU list again without activating so inactive_list_is_low
> on anonymous LRU is always false. IOW, there is no deactivation from active list.
>
> It's just my picture without no clue. ;-)
With latest kernels (4.11.0-0.rc2.git0.2.fc26.x86_64) I'm having the
issue that swapping is active all the time after some runtime (~1day).
top - 07:30:17 up 1 day, 19:42, 1 user, load average: 13.71, 16.98, 15.36
Tasks: 130 total, 2 running, 128 sleeping, 0 stopped, 0 zombie
%Cpu(s): 15.8 us, 33.5 sy, 0.0 ni, 3.9 id, 34.5 wa, 4.9 hi, 1.0 si,
6.4 st
KiB Mem : 369700 total, 5484 free, 311556 used, 52660 buff/cache
KiB Swap: 2064380 total, 1187684 free, 876696 used. 20340 avail Mem
[root@smtp ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system--
------cpu-----
r b swpd free buff cache si so bi bo in cs us sy
id wa st
3 1 876280 7132 16536 64840 238 226 1027 258 80 97 2 3
83 11 1
0 4 876140 3812 10520 64552 3676 168 11840 1100 2255 2582 7
13 8 70 3
0 3 875372 3628 4024 56160 5424 64 10004 476 2157 2580 2
14 0 83 2
0 4 875560 24056 2208 56296 9032 2180 39928 2388 4111 4549 10
32 0 55 3
2 2 875660 7540 5256 58220 5536 1604 48756 1864 4505 4196 12
23 5 58 3
0 3 875264 3664 2120 57596 2304 116 17904 560 2223 1825 15
15 0 67 3
0 2 875564 3800 588 57856 1340 1068 14780 1184 1390 1364 12
10 0 77 3
1 2 875724 3740 372 53988 3104 928 16884 1068 1560 1527 3
12 0 83 3
0 3 881096 3708 532 52220 4604 5872 21004 6104 2752 2259 7
18 5 67 2
The following commit is included in that version:
commit 710531320af876192d76b2c1f68190a1df941b02
Author: Michal Hocko <mhocko@suse.com>
Date: Wed Feb 22 15:45:58 2017 -0800
mm, vmscan: cleanup lru size claculations
commit fd538803731e50367b7c59ce4ad3454426a3d671 upstream.
But still OOMs:
[157048.030760] clamscan: page allocation stalls for 19405ms, order:0,
mode:0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null)
[157048.031985] clamscan cpuset=/ mems_allowed=0
[157048.031993] CPU: 1 PID: 9597 Comm: clamscan Not tainted
4.11.0-0.rc2.git0.2.fc26.x86_64 #1
[157048.033197] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.9.3 04/01/2014
[157048.034382] Call Trace:
[157048.035532] dump_stack+0x63/0x84
[157048.036735] warn_alloc+0x10c/0x1b0
[157048.037768] __alloc_pages_slowpath+0x93d/0xe60
[157048.038873] ? dd_dispatch_request+0x2b/0x1a0
[157048.041033] ? get_page_from_freelist+0x122/0xbf0
[157048.042435] __alloc_pages_nodemask+0x290/0x2b0
[157048.043662] alloc_pages_vma+0xa0/0x2b0
[157048.044796] __read_swap_cache_async+0x146/0x210
[157048.045841] read_swap_cache_async+0x26/0x60
[157048.046858] swapin_readahead+0x186/0x230
[157048.047854] ? radix_tree_lookup_slot+0x22/0x50
[157048.049006] ? find_get_entry+0x20/0x140
[157048.053109] ? pagecache_get_page+0x2c/0x2e0
[157048.054179] do_swap_page+0x276/0x7b0
[157048.055138] __handle_mm_fault+0x6fd/0x1160
[157048.057571] ? pick_next_task_fair+0x48c/0x560
[157048.058608] handle_mm_fault+0xb3/0x250
[157048.059622] __do_page_fault+0x23f/0x4c0
[157048.068926] trace_do_page_fault+0x41/0x120
[157048.070143] do_async_page_fault+0x51/0xa0
[157048.071254] async_page_fault+0x28/0x30
[157048.072606] RIP: 0033:0x7f78659eb675
[157048.073858] RSP: 002b:00007ffcaba111b8 EFLAGS: 00010202
[157048.075192] RAX: 0000000000000941 RBX: 00007f785957e8d0 RCX:
00007f784e968b48
[157048.076609] RDX: 00007f784f87bce8 RSI: 00007f7851fdb0cb RDI:
00007f7866726000
[157048.077809] RBP: 00007f785957e910 R08: 0000000000040000 R09:
0000000000000000
[157048.078935] R10: ffffffffffffff48 R11: 0000000000000246 R12:
00007f78600c81c0
[157048.080028] R13: 00007f785957e970 R14: 00007f78594ffba8 R15:
0000000003406237
[157048.081827] Mem-Info:
[157048.083005] active_anon:19902 inactive_anon:19920 isolated_anon:383
active_file:816 inactive_file:529 isolated_file:0
unevictable:0 dirty:0 writeback:19 unstable:0
slab_reclaimable:4225 slab_unreclaimable:6483
mapped:942 shmem:3 pagetables:3553 bounce:0
free:944 free_pcp:87 free_cma:0
[157048.089470] Node 0 active_anon:79552kB inactive_anon:79588kB
active_file:3108kB inactive_file:2144kB unevictable:0kB
isolated(anon):1624kB isolated(file):0kB mapped:3612kB dirty:0kB
writeback:76kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp:
12kB writeback_tmp:0kB unstable:0kB pages_scanned:247 all_unreclaimable? no
[157048.092318] Node 0 DMA free:1408kB min:104kB low:128kB high:152kB
active_anon:664kB inactive_anon:3124kB active_file:48kB
inactive_file:40kB unevictable:0kB writepending:0kB present:15992kB
managed:15908kB mlocked:0kB slab_reclaimable:564kB
slab_unreclaimable:2148kB kernel_stack:92kB pagetables:1328kB bounce:0kB
free_pcp:0kB local_pcp:0kB free_cma:0kB
[157048.096008] lowmem_reserve[]: 0 327 327 327 327
[157048.097234] Node 0 DMA32 free:2576kB min:2264kB low:2828kB
high:3392kB active_anon:78844kB inactive_anon:76612kB active_file:2840kB
inactive_file:1896kB unevictable:0kB writepending:76kB present:376688kB
managed:353792kB mlocked:0kB slab_reclaimable:16336kB
slab_unreclaimable:23784kB kernel_stack:2388kB pagetables:12884kB
bounce:0kB free_pcp:644kB local_pcp:312kB free_cma:0kB
[157048.101118] lowmem_reserve[]: 0 0 0 0 0
[157048.102190] Node 0 DMA: 37*4kB (UEH) 12*8kB (H) 13*16kB (H) 10*32kB
(H) 4*64kB (H) 3*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB =
1412kB
[157048.104989] Node 0 DMA32: 79*4kB (UMEH) 199*8kB (UMEH) 18*16kB (UMH)
5*32kB (H) 2*64kB (H) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
= 2484kB
[157048.107789] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
[157048.107790] 2027 total pagecache pages
[157048.109125] 710 pages in swap cache
[157048.115088] Swap cache stats: add 36179491, delete 36179123, find
86964755/101977142
[157048.116934] Free swap = 808064kB
[157048.118466] Total swap = 2064380kB
[157048.122828] 98170 pages RAM
[157048.124039] 0 pages HighMem/MovableOnly
[157048.125051] 5745 pages reserved
[157048.125997] 0 pages cma reserved
[157048.127008] 0 pages hwpoisoned
Thnx.
Ciao,
Gerhard
--
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>
next prev parent reply other threads:[~2017-03-16 6:48 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 7:10 Still OOM problems with 4.9er kernels Gerhard Wiesinger
2016-11-30 7:20 ` Gerhard Wiesinger
2016-12-09 7:06 ` Gerhard Wiesinger
2016-12-09 13:40 ` Michal Hocko
2016-12-09 13:40 ` Michal Hocko
2016-12-09 15:52 ` Gerhard Wiesinger
2016-12-09 15:52 ` Gerhard Wiesinger
2016-12-09 15:58 ` Gerhard Wiesinger
2016-12-09 15:58 ` Gerhard Wiesinger
2016-12-09 16:09 ` Michal Hocko
2016-12-09 16:09 ` Michal Hocko
2016-12-09 16:58 ` Gerhard Wiesinger
2016-12-09 17:30 ` Michal Hocko
2016-12-09 17:30 ` Michal Hocko
2016-12-09 18:01 ` Gerhard Wiesinger
2016-12-09 18:01 ` Gerhard Wiesinger
2016-12-09 21:42 ` Vlastimil Babka
2016-12-09 21:42 ` Vlastimil Babka
2016-12-10 13:50 ` Gerhard Wiesinger
2016-12-10 13:50 ` Gerhard Wiesinger
2016-12-12 8:24 ` Michal Hocko
2016-12-12 8:24 ` Michal Hocko
2016-12-23 2:55 ` Minchan Kim
2016-12-23 2:55 ` Minchan Kim
2017-01-01 17:20 ` Gerhard Wiesinger
2017-01-01 17:20 ` Gerhard Wiesinger
2017-01-04 8:40 ` Gerhard Wiesinger
2017-01-04 9:11 ` Michal Hocko
2017-01-04 9:11 ` Michal Hocko
2017-02-26 8:40 ` Still OOM problems with 4.9er/4.10er kernels Gerhard Wiesinger
2017-02-27 8:27 ` Michal Hocko
2017-02-27 8:27 ` Michal Hocko
2017-02-28 6:06 ` Gerhard Wiesinger
2017-02-28 6:06 ` Gerhard Wiesinger
2017-02-28 8:14 ` Michal Hocko
2017-02-28 8:14 ` Michal Hocko
2017-02-27 9:02 ` Minchan Kim
2017-02-27 9:02 ` Minchan Kim
2017-02-27 9:44 ` Michal Hocko
2017-02-27 9:44 ` Michal Hocko
2017-02-28 5:17 ` Minchan Kim
2017-02-28 5:17 ` Minchan Kim
2017-02-28 8:12 ` Michal Hocko
2017-02-28 8:12 ` Michal Hocko
2017-03-02 7:17 ` Minchan Kim
2017-03-02 7:17 ` Minchan Kim
2017-03-16 6:38 ` Gerhard Wiesinger [this message]
2017-03-16 6:38 ` Gerhard Wiesinger
2017-03-16 8:27 ` Michal Hocko
2017-03-16 8:27 ` Michal Hocko
2017-03-16 8:47 ` lkml
2017-03-16 8:47 ` lkml
2017-03-16 9:08 ` Michal Hocko
2017-03-16 9:08 ` Michal Hocko
2017-03-16 9:23 ` lkml
2017-03-16 9:23 ` lkml
2017-03-16 9:39 ` Michal Hocko
2017-03-16 9:39 ` Michal Hocko
2017-03-17 16:37 ` Gerhard Wiesinger
2017-03-17 16:37 ` Gerhard Wiesinger
2017-03-17 17:13 ` Michal Hocko
2017-03-17 17:13 ` Michal Hocko
2017-03-17 20:08 ` Gerhard Wiesinger
2017-03-17 20:08 ` Gerhard Wiesinger
2017-03-19 8:17 ` Gerhard Wiesinger
2017-03-19 8:17 ` Gerhard Wiesinger
2017-03-20 1:54 ` Tetsuo Handa
2017-03-20 1:54 ` Tetsuo Handa
2017-03-19 15:18 ` Michal Hocko
2017-03-19 15:18 ` Michal Hocko
2017-03-19 16:02 ` Gerhard Wiesinger
2017-03-19 16:02 ` Gerhard Wiesinger
2017-03-20 3:05 ` Mike Galbraith
2017-03-20 3:05 ` Mike Galbraith
2017-03-21 5:59 ` Gerhard Wiesinger
2017-03-21 5:59 ` Gerhard Wiesinger
2017-03-21 7:13 ` Mike Galbraith
2017-03-21 7:13 ` Mike Galbraith
2017-03-23 7:16 ` Gerhard Wiesinger
2017-03-23 7:16 ` Gerhard Wiesinger
2017-03-23 8:38 ` Mike Galbraith
2017-03-23 8:38 ` Mike Galbraith
2017-03-23 14:46 ` Tetsuo Handa
2017-03-23 14:46 ` Tetsuo Handa
2017-03-26 8:36 ` Gerhard Wiesinger
2017-03-26 8:36 ` Gerhard Wiesinger
2016-12-09 16:03 ` Still OOM problems with 4.9er kernels Gerhard Wiesinger
2016-12-09 16:03 ` Gerhard Wiesinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=feebcc24-2863-1bdf-e586-1ac9648b35ba@wiesinger.com \
--to=lists@wiesinger.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.