Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp145530pxa; Wed, 26 Aug 2020 07:04:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzGj9PcZcwa0djWcX7Rygx/L8cZ3+ROw+kaOeGn4N6swTMiNUR0zZI8MO4z09/8UndOKspV X-Received: by 2002:a17:906:40e:: with SMTP id d14mr11862932eja.455.1598450684654; Wed, 26 Aug 2020 07:04:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598450684; cv=none; d=google.com; s=arc-20160816; b=utcfFR7cLwFmKHl7zuL5pN94YMbnGcb+JlQIVO6/A3xQR4bIw1iASa7T4VNK2a9Y1z s+QkPXaV5+WtVNft2LzreilST+dcx1rh45v5kFJePl1zoEMxUe0rFeKKYBJf6KaVp+5J f3VD2eUY2v0UVCE2B4PqCPnmwLTRS2HbqdKSz0DFH90TqsyVqIFW8DUjV1S26I+HsDg4 AAZkcahyFPSals63MnDLCyksEjRRItRHtCMoUpwmHZrL6ujsl5d+jXIiqn0vdgOiGskc LNRae74St3MfsFaFzkhRlFKpj49+Kx9Ekd0iRFU+uXXdlcbile8d/5dYJ1pTvly9L/lp 6h9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=WNXUyGo79o68bhzKyU6uduhCodstiOfbQMvpKdRFrmE=; b=ahdpz8FgivVDIPc8IG23pXWl6qxPmeT0E3NcyLOw5wNGZntebKbNQRqQyBAEK9Y4aw K0+FmH+DJmh7uLtLWytLNir+bBCAB59gubKiYaCYU7BewLbe4VuvnzmhmipsVrP0oSG4 dS8WJOIL2FIo4OCBGDKW40wuBEOB+uMUmLUVPopEqJ78aXJR/7D7gQdPvkIJBNTCdLLE ik6UvUwOQIgb6lFURUFmsmYDumUMcQYuDbkIchXkkGlxK7dQtiPKxnvfd7upzHQhfy4O WoUwXnxNP3n/3hzVvKSNm44vIV86BASO3GH/k9ttJLXgsLN5VpXjXjyWaRTq7IfYnAak MB1Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cn3si1450738edb.563.2020.08.26.07.04.21; Wed, 26 Aug 2020 07:04:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726751AbgHZILE (ORCPT + 99 others); Wed, 26 Aug 2020 04:11:04 -0400 Received: from mx2.suse.de ([195.135.220.15]:51488 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726016AbgHZILE (ORCPT ); Wed, 26 Aug 2020 04:11:04 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 795CDAD36; Wed, 26 Aug 2020 08:11:34 +0000 (UTC) Date: Wed, 26 Aug 2020 10:11:02 +0200 From: Michal Hocko To: Xunlei Pang Cc: Johannes Weiner , Andrew Morton , Vladimir Davydov , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm: memcg: Fix memcg reclaim soft lockup Message-ID: <20200826081102.GM22869@dhcp22.suse.cz> References: <1598426822-93737-1-git-send-email-xlpang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1598426822-93737-1-git-send-email-xlpang@linux.alibaba.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 26-08-20 15:27:02, Xunlei Pang wrote: > We've met softlockup with "CONFIG_PREEMPT_NONE=y", when > the target memcg doesn't have any reclaimable memory. Do you have any scenario when this happens or is this some sort of a test case? > It can be easily reproduced as below: > watchdog: BUG: soft lockup - CPU#0 stuck for 111s![memcg_test:2204] > CPU: 0 PID: 2204 Comm: memcg_test Not tainted 5.9.0-rc2+ #12 > Call Trace: > shrink_lruvec+0x49f/0x640 > shrink_node+0x2a6/0x6f0 > do_try_to_free_pages+0xe9/0x3e0 > try_to_free_mem_cgroup_pages+0xef/0x1f0 > try_charge+0x2c1/0x750 > mem_cgroup_charge+0xd7/0x240 > __add_to_page_cache_locked+0x2fd/0x370 > add_to_page_cache_lru+0x4a/0xc0 > pagecache_get_page+0x10b/0x2f0 > filemap_fault+0x661/0xad0 > ext4_filemap_fault+0x2c/0x40 > __do_fault+0x4d/0xf9 > handle_mm_fault+0x1080/0x1790 > > It only happens on our 1-vcpu instances, because there's no chance > for oom reaper to run to reclaim the to-be-killed process. > > Add cond_resched() in such cases at the beginning of shrink_lruvec() > to give up the cpu to others. I do agree that we need a cond_resched but I cannot say I would like this patch. The primary reason is that it doesn't catch all cases when the memcg is not reclaimable. For example it wouldn't reschedule if the memcg is protected by low/min. What do you think about this instead? diff --git a/mm/vmscan.c b/mm/vmscan.c index 99e1796eb833..bbdc38b58cc5 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2617,6 +2617,8 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) mem_cgroup_calculate_protection(target_memcg, memcg); + cond_resched(); + if (mem_cgroup_below_min(memcg)) { /* * Hard protection. This should catch both cases. I even have a vague recollection that somebody has proposed something in that direction but I cannot remember what has happened with that patch. -- Michal Hocko SUSE Labs