From patchwork Thu Jul 9 19:47:18 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roman Gushchin X-Patchwork-Id: 11655005 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 86E4060D for ; Thu, 9 Jul 2020 19:49:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 51D21206DF for ; Thu, 9 Jul 2020 19:49:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=fb.com header.i=@fb.com header.b="VMuN6zuQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 51D21206DF Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=fb.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 623336B0003; Thu, 9 Jul 2020 15:49:45 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 5F9B46B0005; Thu, 9 Jul 2020 15:49:45 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50E9C6B0006; Thu, 9 Jul 2020 15:49:45 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) by kanga.kvack.org (Postfix) with ESMTP id 3BE1B6B0003 for ; Thu, 9 Jul 2020 15:49:45 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id EEE21180AD801 for ; Thu, 9 Jul 2020 19:49:44 +0000 (UTC) X-FDA: 77019577488.02.trail79_0201e6d26ec8 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id B09D8400021378F1 for ; Thu, 9 Jul 2020 19:49:44 +0000 (UTC) X-Spam-Summary: 1,0,0,19d0165835326784,d41d8cd98f00b204,prvs=44593ec29d=guro@fb.com,,RULES_HIT:41:355:379:541:800:960:973:988:989:1260:1261:1277:1311:1313:1314:1345:1437:1513:1515:1516:1518:1521:1535:1542:1711:1730:1747:1777:1792:2198:2199:2393:2559:2562:2731:2895:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:4321:5007:6119:6261:6653:7903:8531:9592:9707:10004:10400:10450:10455:11026:11658:11914:12043:12295:12296:12297:12438:12555:12895:13161:13221:13229:14096:14097:14181:14394:14721:19904:19999:21080:21451:21627:21740:21795:21990:30051:30054:30064:30070,0,RBL:67.231.153.30:@fb.com:.lbl8.mailshell.net-62.12.0.100 64.201.201.201;04yf9gk8nt4ajwpzir6zkuuh8cet3opg578ow6btnqcs4xqgosex6cx75urchor.fqnenq93rkuiuco9j49tgzpo8x7uo5a5ym3pbfheqdjz7h6eaqrkbsws1p69h5z.h-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: trail79_0201e6d26ec8 X-Filterd-Recvd-Size: 5103 Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Thu, 9 Jul 2020 19:49:44 +0000 (UTC) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 069Jmipr032460 for ; Thu, 9 Jul 2020 12:49:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding : content-type; s=facebook; bh=VTWpfdegGrdDxghOVyqFUEPk3n1YllDq3XWueA4lSxw=; b=VMuN6zuQzpMD4v35bNRUtv8IyC4teP8JJRBYsUt3OxBws+9ut6JPx+gWQwwSj9CFriar 2/CpaOPyI4/XCkEJXpMihvtbGdLDy37BXBTuEsXdPv0XSJ/UOOMaKBA2/C+IvcwOTqTp SxRqTlKrJfImIQ9FtNZGCGF3/sX7XtC5rfQ= Received: from mail.thefacebook.com ([163.114.132.120]) by mx0a-00082601.pphosted.com with ESMTP id 325k2cecfp-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 09 Jul 2020 12:49:43 -0700 Received: from intmgw002.41.prn1.facebook.com (2620:10d:c085:208::11) by mail.thefacebook.com (2620:10d:c085:11d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 9 Jul 2020 12:49:41 -0700 Received: by devvm1096.prn0.facebook.com (Postfix, from userid 111017) id D7B92E571FB; Thu, 9 Jul 2020 12:47:30 -0700 (PDT) Smtp-Origin-Hostprefix: devvm From: Roman Gushchin Smtp-Origin-Hostname: devvm1096.prn0.facebook.com To: Andrew Morton CC: Johannes Weiner , Michal Hocko , Shakeel Butt , , , , Roman Gushchin , Domas Mituzas , Tejun Heo , Chris Down Smtp-Origin-Cluster: prn0c01 Subject: [PATCH] mm: memcontrol: avoid workload stalls when lowering memory.high Date: Thu, 9 Jul 2020 12:47:18 -0700 Message-ID: <20200709194718.189231-1-guro@fb.com> X-Mailer: git-send-email 2.24.1 MIME-Version: 1.0 X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-07-09_10:2020-07-09,2020-07-09 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 phishscore=0 spamscore=0 priorityscore=1501 clxscore=1015 malwarescore=0 adultscore=0 lowpriorityscore=0 mlxscore=0 suspectscore=0 bulkscore=0 impostorscore=0 mlxlogscore=716 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007090133 X-FB-Internal: deliver X-Rspamd-Queue-Id: B09D8400021378F1 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Memory.high limit is implemented in a way such that the kernel penalizes all threads which are allocating a memory over the limit. Forcing all threads into the synchronous reclaim and adding some artificial delays allows to slow down the memory consumption and potentially give some time for userspace oom handlers/resource control agents to react. It works nicely if the memory usage is hitting the limit from below, however it works sub-optimal if a user adjusts memory.high to a value way below the current memory usage. It basically forces all workload threads (doing any memory allocations) into the synchronous reclaim and sleep. This makes the workload completely unresponsive for a long period of time and can also lead to a system-wide contention on lru locks. It can happen even if the workload is not actually tight on memory and has, for example, a ton of cold pagecache. In the current implementation writing to memory.high causes an atomic update of page counter's high value followed by an attempt to reclaim enough memory to fit into the new limit. To fix the problem described above, all we need is to change the order of execution: try to push the memory usage under the limit first, and only then set the new high limit. Signed-off-by: Roman Gushchin Reported-by: Domas Mituzas Cc: Johannes Weiner Cc: Michal Hocko Cc: Tejun Heo Cc: Shakeel Butt Cc: Chris Down Acked-by: Michal Hocko Reviewed-by: Shakeel Butt --- mm/memcontrol.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index b8424aa56e14..4b71feee7c42 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6203,8 +6203,6 @@ static ssize_t memory_high_write(struct kernfs_open_file *of, if (err) return err; - page_counter_set_high(&memcg->memory, high); - for (;;) { unsigned long nr_pages = page_counter_read(&memcg->memory); unsigned long reclaimed; @@ -6228,6 +6226,8 @@ static ssize_t memory_high_write(struct kernfs_open_file *of, break; } + page_counter_set_high(&memcg->memory, high); + return nbytes; }