From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24B0FC6FD1D for ; Fri, 17 Mar 2023 18:06:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229838AbjCQSGX (ORCPT ); Fri, 17 Mar 2023 14:06:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230029AbjCQSGW (ORCPT ); Fri, 17 Mar 2023 14:06:22 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E91D206AD for ; Fri, 17 Mar 2023 11:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679076335; 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=UIc+3uJLQO2epi9c5c7YBS9m+h9LmNMS++rx41y2Zn0=; b=NMv1AMPJSPkewjPbruq/EENxrv6IVB0QH5S57VFvKGldR7PNS0Cz83KPbLVbTzjM10BHMo tTGP5i5ckJFa0dvZmmbeBqIsYYL1RQzdBfkb0h6z6Z4maG2wWB5r+3YmuspEP2xfZ+iWHH BsXTBsFConJtRtV8rxqCxNORAbQhlck= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-645-gD9KEK47O7-cDd1-m1Er1g-1; Fri, 17 Mar 2023 14:05:34 -0400 X-MC-Unique: gD9KEK47O7-cDd1-m1Er1g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D1E0C96DC8C; Fri, 17 Mar 2023 18:05:32 +0000 (UTC) Received: from [10.22.10.238] (unknown [10.22.10.238]) by smtp.corp.redhat.com (Postfix) with ESMTP id 436EC2027046; Fri, 17 Mar 2023 18:05:32 +0000 (UTC) Message-ID: <11b5454b-42c7-fb0d-f071-c46712f76f3b@redhat.com> Date: Fri, 17 Mar 2023 14:05:32 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v2 3/4] cgroup/cpuset: Include offline CPUs when tasks' cpumasks in top_cpuset are updated Content-Language: en-US To: =?UTF-8?Q?Michal_Koutn=c3=bd?= Cc: Tejun Heo , Zefan Li , Johannes Weiner , Shuah Khan , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Will Deacon , Peter Zijlstra , Juri Lelli References: <20230317151508.1225282-1-longman@redhat.com> <20230317151508.1225282-4-longman@redhat.com> <20230317180157.uqlleobldg53pgj6@blackpad> From: Waiman Long In-Reply-To: <20230317180157.uqlleobldg53pgj6@blackpad> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On 3/17/23 14:01, Michal Koutný wrote: > Hello. > > On Fri, Mar 17, 2023 at 11:15:07AM -0400, Waiman Long wrote: >> * Iterate through each task of @cs updating its cpus_allowed to the >> * effective cpuset's. As this function is called with cpuset_rwsem held, >> - * cpuset membership stays stable. >> + * cpuset membership stays stable. For top_cpuset, task_cpu_possible_mask() >> + * is used instead of effective_cpus to make sure all offline CPUs are also >> + * included as hotplug code won't update cpumasks for tasks in top_cpuset. >> */ > On Wed, Mar 15, 2023 at 11:06:20AM +0100, Michal Koutný wrote: >> I see now that it returns offlined cpus to top cpuset's tasks. > I considered only the "base" set change cs->effective_cpus -> > possible_mask. (Apologies for that mistake.) > > However, I now read the note about subparts_cpus > >> * effective_cpus contains only onlined CPUs, but subparts_cpus >> * may have offlined ones. > So if subpart_cpus keeps offlined CPUs, they will be subtracted from > possible_mask and absent in the resulting new_cpus, i.e. undesirable for > the tasks in that cpuset :-/ A cpu will be in the subparts_cpus only if it has been given to the child partition. So when it becomes online, it will become part of the scheduling domain that child partition. Only the tasks in that child partition will get their cpumasks updated to use it, not those in the top cpuset. Cheers, Longman