Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp599752pxb; Wed, 27 Oct 2021 08:48:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyt/f8RuXls5JsIfk6jpaWk8ASoWbpUU/9KoQh72jd4xttsOQfmIMYxTYoZMBkxI6TcT/0k X-Received: by 2002:a50:d4cd:: with SMTP id e13mr45394276edj.29.1635349709726; Wed, 27 Oct 2021 08:48:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635349709; cv=none; d=google.com; s=arc-20160816; b=VrPbklpPPhM8Zy4oayKdyae0UsEAAxmmw2gzertuiI4HittC9U0s32QL7MEPXvunlS 2IT44igiNbkqQVxlG0CXK2cl/tcCYPSNC2rty+IPFzDoqN9RU3hL1mPkjWyE4BZzLlwv wEB5Q9c4Rm/FAcvA2eKoLDaZUYu3EYJDuKaaTWAsPPYD1PPjwITs8sYj/5592Jx4GOnt tYIYkkn9c+dEfbl76ppmpKoYPUspVpzoBBFLjiD3s6RmvFvABgb6vfpmeTI+4TsioRat suVC7G+mknseBf6JMwcSONRbUrG/VbBVAZtMTV6oLxS9ZYF0j/LbmYdYLBvNA+bQCPmW pV3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=ZGUktUxKSDawe5cfrBBp7LiAKurPgQ7WEWiThb4tO84=; b=xNmM2WktzbKjO+L7e0Qo6vvVMqadIj8j6Vp69dB5CuOIEfPPDqPlhgvuBzD7/wyKpN v7hFqtRfSPbOkmwbAD12oQQXjVL+/DctTryzziObhktNd+3MGuLKZoBhNob7bUlG98o4 nMaX+p/WnSTMg1D826Hj2ZNczC8l4+56aXs/kUBoexvnIUH9sXQ1EMC5j4ZWupmdSzld EBDso6UlA0u6LoPJ5sgRHjb+ZFrq4FXe4u0Iw4xKxqrdcxQPq1URyWVEtf6SZnBNNa2R qJEq/x1ek58hikTQ+gfJ/X9Ut8edSjxfpbC/0jGfSerGzlRtWZj9Hw+g+8dT5xMIH8qn Femg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AnXggKiM; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i25si280213ejd.303.2021.10.27.08.48.03; Wed, 27 Oct 2021 08:48:29 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AnXggKiM; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234283AbhJ0CiL (ORCPT + 99 others); Tue, 26 Oct 2021 22:38:11 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:55041 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232502AbhJ0CiK (ORCPT ); Tue, 26 Oct 2021 22:38:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635302145; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZGUktUxKSDawe5cfrBBp7LiAKurPgQ7WEWiThb4tO84=; b=AnXggKiMLWnBBVx4FJ8HdZnkvwEG30Cx2DX56eyZ4FbNd7Wvvf/CIytZfCcw6QqXs4tmrx duAjVynq+bclCENpQ1UTYpptrhfARrtKPg+8rtjcrGY1132Nt/boQeUwxCfpD2sWhxRjna 0zfQR4dGv4F2wtHa8+28i8CpbcRzghQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-442-alal8p15ORiT81NlvQelWA-1; Tue, 26 Oct 2021 22:35:40 -0400 X-MC-Unique: alal8p15ORiT81NlvQelWA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2173010A8E00; Wed, 27 Oct 2021 02:35:38 +0000 (UTC) Received: from llong.remote.csb (unknown [10.22.18.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id ED7D7ADD8; Wed, 27 Oct 2021 02:35:35 +0000 (UTC) Subject: Re: [PATCH RFC] cpuset: Make cpusets get restored on hotplug To: Barry Song <21cnbao@gmail.com> Cc: amit.pundir@linaro.org, cgroups@vger.kernel.org, Dmitry Shmidt , groeck@chromium.org, hannes@cmpxchg.org, joel@joelfernandes.org, jsbarnes@google.com, kernel-team@android.com, kerrnel@google.com, LKML , lizefan@huawei.com, Peter Zijlstra , sonnyrao@google.com, Tejun Heo , vpillai@digitalocean.com References: <972a5c1b-6721-ac20-cec5-617af67e617d@redhat.com> <20211026235808.34168-1-21cnbao@gmail.com> From: Waiman Long Message-ID: <4637ebd4-61ef-5ad6-d2bd-976663f5c4a1@redhat.com> Date: Tue, 26 Oct 2021 22:35:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/26/21 10:21 PM, Barry Song wrote: > On Wed, Oct 27, 2021 at 2:06 PM Waiman Long wrote: >> >> On 10/26/21 7:58 PM, Barry Song wrote: >>>> I think Tejun is concerned about a change in the default behavior of >>>> cpuset v1. >>>> >>>> There is a special v2 mode for cpuset that is enabled by the mount >>>> option "cpuset_v2_mode". This causes the cpuset v1 to adopt some of the >>>> v2 behavior. I introduced this v2 mode a while back to address, I think, >>>> a similar concern. Could you try that to see if it is able to address >>>> your problem? If not, you can make some code adjustment within the >>>> framework of the v2 mode. As long as it is an opt-in, I think we are >>>> open to further change. >>> I am also able to reproduce on Ubuntu 21.04 LTS. >>> >>> all docker will be put in this cgroups and its child cgroups: >>> /sys/fs/cgroup/cpuset/docker >>> >>> disabling and enabling SMT by: >>> echo off > /sys/devices/system/cpu/smt/control >>> echo on > /sys/devices/system/cpu/smt/control >>> >>> or unpluging and pluging CPUs by: >>> echo 0 > /sys/devices/system/cpu/cpuX/online >>> echo 1 > /sys/devices/system/cpu/cpuX/online >>> >>> then all docker images will lose some CPUs. >>> >>> So should we document the broken behaviours somewhere? >> Is the special cpuset_v2_mode mount option able to fix the issue? >> >> This mode is documented in >> >> Documentation/admin-guide/cgroup-v1/cpuset.rst: >> >> The cpuset.effective_cpus and cpuset.effective_mems files are >> normally read-only copies of cpuset.cpus and cpuset.mems files >> respectively. If the cpuset cgroup filesystem is mounted with the >> special "cpuset_v2_mode" option, the behavior of these files will become >> similar to the corresponding files in cpuset v2. In other words, hotplug >> events will not change cpuset.cpus and cpuset.mems. Those events will >> only affect cpuset.effective_cpus and cpuset.effective_mems which show >> the actual cpus and memory nodes that are currently used by this cpuset. >> See Documentation/admin-guide/cgroup-v2.rst for more information about >> cpuset v2 behavior. >> >> Maybe we can make it more visible. > Is it possible to make cpuset_v2_mode true in default? not quite sure if > it will harm something. The cpuset_v2_mode is a change in v1 behavior and that is why it is an opt-in as we don't want to break existing applications that have a dependency on the current v1 behavior. If users switch to use cgroup v2, they get the new behavior. Alternately, they can modify the system startup script to use the v2 behavior by using the mount option. I don't think we are going to change the v1 default behavior. Cheers, Longman