Received: by 10.213.65.68 with SMTP id h4csp873176imn; Tue, 27 Mar 2018 10:20:20 -0700 (PDT) X-Google-Smtp-Source: AIpwx48FDPXj1zLyWAiBQn5jFyJnguTBlp7ygLsdTzyxiCahUGZLN08I/z6dfqe9wk1hchoDILxE X-Received: by 2002:a17:902:5489:: with SMTP id e9-v6mr190084pli.306.1522171219997; Tue, 27 Mar 2018 10:20:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522171219; cv=none; d=google.com; s=arc-20160816; b=bx3qByFf/u9oLU4Zmfz6yDOwL1w83j4aqx19aAA5cjXWDGXC228upy49MoL+GpsTkb zrnLaHxY9Hu8vsMPhXmIj/Rzs5XixXkriiOz+XciJt2k/NvN7yzdefuosxUZ5bPJgxkV MhHlv3Qckn33oEQ/CDfHEn60wc8hLP+z5Mh5bMCF3yqBPkAtC++litoWg4K7NEAeKYq9 cGqa7nH2eECJN/iQ4ikRFozSi00Em4oqb+ZviAjZNfXub4HfycBwELUq+EgPxjUKFGjX 7WFS/h7YXOyC/sGoSbgLJjcH1BVzMjCR9ZhPWDumVJy8kep+I1EB8iu7antWFNMBWXku CMSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=ZYrlZSqDFZK2fGNbYYuzxYp1fB6i5TzmmWKb5MG2iHA=; b=dxJ9IM6q1bW9DRPRPbg6zWa3mO3/oM0qQnBxBy5Q+VSRizp9orEnLa7e9HkFhWVFui h7ZSXYOoizZIWQcpzp0grdYeOCzQ+S+fX1rnxWTowqhlmHrSYCcDBFsK9oSvDX+vSwod tPAyWymRLUDAPldmS5BrmZReoxcZfe2ecsWKFuMmwBfKLvc5/jozCQsOJ88LENwDAMzs faXzZSyOPlbISwhGwAuIcpYRdsEDtARvBiILaePrqGFw5jBRd4KY26nh1HntUnw112cg H+FAEv16MrBE7ufZSv+gcsibVqevg9+hAjRPZozg7ivoU4Pjf7qux+dWfLIWOSfVCcs1 oPqw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m11-v6si1554512pls.337.2018.03.27.10.20.05; Tue, 27 Mar 2018 10:20:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752895AbeC0RSU (ORCPT + 99 others); Tue, 27 Mar 2018 13:18:20 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46712 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755178AbeC0QiV (ORCPT ); Tue, 27 Mar 2018 12:38:21 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 83E08F92; Tue, 27 Mar 2018 16:38:20 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andrey Ryabinin , Shakeel Butt , Michal Hocko , Mel Gorman , Tejun Heo , Johannes Weiner , Andrew Morton , Linus Torvalds Subject: [PATCH 4.14 058/101] mm/vmscan: wake up flushers for legacy cgroups too Date: Tue, 27 Mar 2018 18:27:30 +0200 Message-Id: <20180327162753.545466903@linuxfoundation.org> X-Mailer: git-send-email 2.16.3 In-Reply-To: <20180327162749.993880276@linuxfoundation.org> References: <20180327162749.993880276@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Andrey Ryabinin commit 1c610d5f93c709df56787f50b3576704ac271826 upstream. Commit 726d061fbd36 ("mm: vmscan: kick flushers when we encounter dirty pages on the LRU") added flusher invocation to shrink_inactive_list() when many dirty pages on the LRU are encountered. However, shrink_inactive_list() doesn't wake up flushers for legacy cgroup reclaim, so the next commit bbef938429f5 ("mm: vmscan: remove old flusher wakeup from direct reclaim path") removed the only source of flusher's wake up in legacy mem cgroup reclaim path. This leads to premature OOM if there is too many dirty pages in cgroup: # mkdir /sys/fs/cgroup/memory/test # echo $$ > /sys/fs/cgroup/memory/test/tasks # echo 50M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes # dd if=/dev/zero of=tmp_file bs=1M count=100 Killed dd invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0 Call Trace: dump_stack+0x46/0x65 dump_header+0x6b/0x2ac oom_kill_process+0x21c/0x4a0 out_of_memory+0x2a5/0x4b0 mem_cgroup_out_of_memory+0x3b/0x60 mem_cgroup_oom_synchronize+0x2ed/0x330 pagefault_out_of_memory+0x24/0x54 __do_page_fault+0x521/0x540 page_fault+0x45/0x50 Task in /test killed as a result of limit of /test memory: usage 51200kB, limit 51200kB, failcnt 73 memory+swap: usage 51200kB, limit 9007199254740988kB, failcnt 0 kmem: usage 296kB, limit 9007199254740988kB, failcnt 0 Memory cgroup stats for /test: cache:49632KB rss:1056KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:49500KB writeback:0KB swap:0KB inactive_anon:0KB active_anon:1168KB inactive_file:24760KB active_file:24960KB unevictable:0KB Memory cgroup out of memory: Kill process 3861 (bash) score 88 or sacrifice child Killed process 3876 (dd) total-vm:8484kB, anon-rss:1052kB, file-rss:1720kB, shmem-rss:0kB oom_reaper: reaped process 3876 (dd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Wake up flushers in legacy cgroup reclaim too. Link: http://lkml.kernel.org/r/20180315164553.17856-1-aryabinin@virtuozzo.com Fixes: bbef938429f5 ("mm: vmscan: remove old flusher wakeup from direct reclaim path") Signed-off-by: Andrey Ryabinin Tested-by: Shakeel Butt Acked-by: Michal Hocko Cc: Mel Gorman Cc: Tejun Heo Cc: Johannes Weiner Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/vmscan.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1847,6 +1847,20 @@ shrink_inactive_list(unsigned long nr_to set_bit(PGDAT_WRITEBACK, &pgdat->flags); /* + * If dirty pages are scanned that are not queued for IO, it + * implies that flushers are not doing their job. This can + * happen when memory pressure pushes dirty pages to the end of + * the LRU before the dirty limits are breached and the dirty + * data has expired. It can also happen when the proportion of + * dirty pages grows not through writes but through memory + * pressure reclaiming all the clean cache. And in some cases, + * the flushers simply cannot keep up with the allocation + * rate. Nudge the flusher threads in case they are asleep. + */ + if (stat.nr_unqueued_dirty == nr_taken) + wakeup_flusher_threads(0, WB_REASON_VMSCAN); + + /* * Legacy memcg will stall in page writeback so avoid forcibly * stalling here. */ @@ -1858,22 +1872,9 @@ shrink_inactive_list(unsigned long nr_to if (stat.nr_dirty && stat.nr_dirty == stat.nr_congested) set_bit(PGDAT_CONGESTED, &pgdat->flags); - /* - * If dirty pages are scanned that are not queued for IO, it - * implies that flushers are not doing their job. This can - * happen when memory pressure pushes dirty pages to the end of - * the LRU before the dirty limits are breached and the dirty - * data has expired. It can also happen when the proportion of - * dirty pages grows not through writes but through memory - * pressure reclaiming all the clean cache. And in some cases, - * the flushers simply cannot keep up with the allocation - * rate. Nudge the flusher threads in case they are asleep, but - * also allow kswapd to start writing pages during reclaim. - */ - if (stat.nr_unqueued_dirty == nr_taken) { - wakeup_flusher_threads(0, WB_REASON_VMSCAN); + /* Allow kswapd to start writing pages during reclaim. */ + if (stat.nr_unqueued_dirty == nr_taken) set_bit(PGDAT_DIRTY, &pgdat->flags); - } /* * If kswapd scans pages marked marked for immediate