Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp544611pxb; Wed, 27 Oct 2021 07:51:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyXsbcI3ZdqXibLeamGg1rTpOTfR5+Y/l0VSEl/lzslwRpE7PTMd93lgpvy6gHNtr0bXNOV X-Received: by 2002:a05:6a00:238d:b0:47c:2232:80d8 with SMTP id f13-20020a056a00238d00b0047c223280d8mr6122728pfc.12.1635346313287; Wed, 27 Oct 2021 07:51:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635346313; cv=none; d=google.com; s=arc-20160816; b=MbiVRGLKpyPbUpmiKk2JjNGHgqg/g804ObNngg+MKN8ZZvtQqKp+KVfCrZkp95hel3 1Cd6P18K/cPcBHW96cuFHiVzjG3aP9u+ozSYrdROKyZ+p3FUrmx2iLksRJ3P90RmQqpR 0kqj3HlET2r0+OuX+7RXmQ5GsNBYBDs9rGlNjkHyDOR4wyENgbW9Iyxvch5+N9ZJ/ZY2 3hfqihUyNXqdBaqJ+w9fU6lA3eFFyOg5x4R/akawWERJYyX06zv2edQeV0CCPaRP8/WU 4ZmY84BxQV1uEvYCowiMGANka4Ltz1t3pJbtIvWUC/+oQ7t81/xE84RdmFsv/ZPhXDch V/Ew== 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=d0sd05fNlpWtdgtTRa/aTogQfojInzQIx5Zn8GaYdz8=; b=ac5kabCV7LqHbTkwQBCwgGzCGD8iMLRAlV7XoeU7iZR85F6eL30WYiAm5Vo4gHzjs+ crAazcV6J5LwbwbNUFXRNl/z/LhSwsdwrRUki1qwGVKMduguOQA7gkYU+DaTEQDpy2ii FKYsLPh7QQUoVj01m+iCQvNh+tsMvpPLz1fXSA210C6i8KMhVbjSibLJHRaDCHVr8oSZ ve4DkrSFgNCWMV6Am53aeCuV8kZwYXfuy4mmjrzmk09antluHZPZSkxWGLg9J7EsWFw1 dLlTzaK9kAJqsksmM5e5bWvVepM0Q50+h2W+HGPSdDBYSX7L4QqMq1YkFlQHLQNOPOQ/ 9Ckw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IdvJpgCB; 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 k3si356188pfc.18.2021.10.27.07.51.16; Wed, 27 Oct 2021 07:51:53 -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=IdvJpgCB; 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 S236731AbhJ0BJW (ORCPT + 99 others); Tue, 26 Oct 2021 21:09:22 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:38325 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231388AbhJ0BJU (ORCPT ); Tue, 26 Oct 2021 21:09:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1635296815; 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=d0sd05fNlpWtdgtTRa/aTogQfojInzQIx5Zn8GaYdz8=; b=IdvJpgCBPT/Hg8z0rosHQzW7l1Yw6kwunTcI2jJQp4dMki6GJlw4m3Hn3c+zNaWh5rapWI GoJxD8gojE8jKScAFEAkpNSF7i40LoSukInC+8s28r6mqpUCry848mloY4so3jD6eiRf6X 8HuuMtV8CbLN0+MMYJoOi3fKZIpmWnk= 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-295-lRAYJofHMV2SNMI6IBGqTQ-1; Tue, 26 Oct 2021 21:06:52 -0400 X-MC-Unique: lRAYJofHMV2SNMI6IBGqTQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A6C46801AE8; Wed, 27 Oct 2021 01:06:49 +0000 (UTC) Received: from llong.remote.csb (unknown [10.22.18.130]) by smtp.corp.redhat.com (Postfix) with ESMTP id 84C115F4EE; Wed, 27 Oct 2021 01:06:47 +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, dimitrysh@google.com, groeck@chromium.org, hannes@cmpxchg.org, joel@joelfernandes.org, jsbarnes@google.com, kernel-team@android.com, kerrnel@google.com, linux-kernel@vger.kernel.org, lizefan@huawei.com, peterz@infradead.org, sonnyrao@google.com, tj@kernel.org, vpillai@digitalocean.com References: <972a5c1b-6721-ac20-cec5-617af67e617d@redhat.com> <20211026235808.34168-1-21cnbao@gmail.com> From: Waiman Long Message-ID: Date: Tue, 26 Oct 2021 21:06:47 -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: <20211026235808.34168-1-21cnbao@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Cheers, Longman