Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2680266iog; Mon, 27 Jun 2022 00:05:43 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uYA3i3zfGzB5O/2WdckDeqGZyjTvEf684UfsRqjGW/zlX6KPtfjY3p3UTycJA16Lj5YoKb X-Received: by 2002:a17:902:ce85:b0:16a:4637:c4da with SMTP id f5-20020a170902ce8500b0016a4637c4damr13295803plg.82.1656313543716; Mon, 27 Jun 2022 00:05:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656313543; cv=none; d=google.com; s=arc-20160816; b=RXUWGLdS4a/QurqZd0OgE4KO9zAsiEZH1bU3LA5HvWz9eoLOder5ir3A6GIm7+wFEE F36xkr9X3cJ9447KM7ETkcowQ/pjRewFogUAHv+5h0yjhqBlC7+04NMSZ885ee0Epe7r uiwBqE5wtjnA1Z/YOsVt2Yd+LMT22iFDlvhijAeW+BVNVJL32/ycyyolcADFAqmrQjmi CsGg91SpC38fnxEiw3zEmUZ1C0CZR2pqSdCIvGuHIlfpQwTJIR2Y6Z7D3bs0lugs9mpS 012EGENjdZeFyk+tOMvdfPBlYaOmz4YKcf+A6X9y+dNDKGc3u52mafPp5M4mlywmjNZg 9zXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject:from :user-agent:mime-version:date:message-id; bh=1Y/ijsdfA5qECYdZAfZEkUuh5ckEzF5UGIreCdsDmY0=; b=J+/IAs+lASmbn7A7/XhjVHvXjmQg8rNKXqkt6UqVkA2B2vD7y0905140IbOiqqMvVA OJzqbVuSGNzMd7BrwXSywA7JurOLIR1NGgQXkJpVU7iAs1uWfpQfYwMvhOFdoIqTLWLP To0zWUu8iPEir69uO64/34MpXeXTJ7qmqaQESMnWdm/c9tAVzic6v09E9QQXldXd03Av 9XnuX05hyzFbd0+mQbIgv4Dl9/g9aQxb62Fez3utFgpVMPd2QtYCkrtWzSngfnbI6YdZ nj+wvfIIWG8CpmRoluZm/n50PmczACZV/Jp0Tpw5lnWL0uzaik11gfrlU1cA4lMSwWER l/Zg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e17-20020a170903241100b001542a6e4c9bsi12834586plo.485.2022.06.27.00.05.31; Mon, 27 Jun 2022 00:05:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232503AbiF0Gub (ORCPT + 99 others); Mon, 27 Jun 2022 02:50:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232320AbiF0Gua (ORCPT ); Mon, 27 Jun 2022 02:50:30 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78F3726C5; Sun, 26 Jun 2022 23:50:28 -0700 (PDT) Received: from dggpeml500022.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4LWdYs5GQtzShYT; Mon, 27 Jun 2022 14:46:57 +0800 (CST) Received: from dggpeml500018.china.huawei.com (7.185.36.186) by dggpeml500022.china.huawei.com (7.185.36.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 27 Jun 2022 14:50:26 +0800 Received: from [10.67.111.186] (10.67.111.186) by dggpeml500018.china.huawei.com (7.185.36.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 27 Jun 2022 14:50:25 +0800 Message-ID: <5987be34-b527-4ff5-a17d-5f6f0dc94d6d@huawei.com> Date: Mon, 27 Jun 2022 14:50:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 From: Zhang Qiao Subject: [Question] The system may be stuck if there is a cpu cgroup cpu.cfs_quato_us is very low To: Tejun Heo , , , Juri Lelli , Vincent Guittot CC: , , , lkml , , , , , Steven Rostedt , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.111.186] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpeml500018.china.huawei.com (7.185.36.186) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, I'm working on debuging a problem. The testcase does follew operations: 1) create a test task cgroup, set cpu.cfs_quota_us=2000,cpu.cfs_period_us=100000. 2) run 20 test_fork[1] test process in the test task cgroup. 3) create 100 new containers: for i in {1..100}; do docker run -itd --health-cmd="ls" --health-interval=1s ubuntu:latest bash; done These operations are expected to succeed and 100 containers create success. however, when creating containers, the system will get stuck and create container failed. After debug this, I found the test_fork process frequently sleep in freezer_fork()->mutex_lock()->might_sleep() with taking the cgroup_threadgroup_rw_sem lock, as follow: copy_process(): cgroup_can_fork() ---> lock cgroup_threadgroup_rw_sem sched_cgroup_fork(); ->task_fork_fair(){ ->update_curr(){ ->__account_cfs_rq_runtime() { resched_curr(); ---> the quota is used up, and set flag TIF_NEED_RESCHED to current } cgroup_post_fork(); ->feezer_fork() ->mutex_lock() { ->might_sleep() ---> schedule() and the current task will be throttled long time. ->cgroup_css_set_put_fork() ---> unlock cgroup_threadgroup_rw_sem Becuase the task cgroup's cpu.cfs_quota_us is very small and test_fork's load is very heavy, the test_fork may be throttled long time, therefore, the cgroup_threadgroup_rw_sem read lock is held for a long time, other processes will get stuck waiting for the lock: 1) a task fork child, will wait at copy_process()->cgroup_can_fork(); 2) a task exiting will wait at exit_signals(); 3) a task write cgroup.procs file will wait at cgroup_file_write()->__cgroup1_procs_write(); ... even the whole system will get stuck. Anyone know how to slove this? Except for changing the cpu.cfs_quota_us. [1] test_fork.c #include #include #include #include int main(int argc, char **argv) { pid_t pid; int count = 20; while(1) { for (int i = 0; i < count; i++) { if ((pid = fork()) <0) { printf("fork error"); return 1; } else if (pid ==0) { exit(0); } } for (int i = 0; i < count; i++) { wait(NULL); } sleep(1); } return 0; } Thanks a lot. -Qiao -