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 8B366C6FD1D for ; Wed, 15 Mar 2023 17:00:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231775AbjCORAM (ORCPT ); Wed, 15 Mar 2023 13:00:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232062AbjCORAI (ORCPT ); Wed, 15 Mar 2023 13:00:08 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7271D1CF4C for ; Wed, 15 Mar 2023 09:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678899560; 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=mo4/ufj5aP4JcG4WHWN3/PJ1VlRuoKnOT1MocwMtouQ=; b=itWDuQMeobWcyfbXODiCPtJ1hqQSLQZDCu7DUNtfK4jtsq6dsQK2pKoRxTZE0NRnWHOX/M qeZZM2JH94Jik+dZSN7aUp8NbBn+3HRxyCFWEfcsTh8vohvd4zUPKvaVN4MkMkddUeD6fN HvaOQ6mqlCg9GMjt7IGKr7reqP5QO70= 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-486-k0Oy4AX3PwuBr33IhirytA-1; Wed, 15 Mar 2023 12:59:14 -0400 X-MC-Unique: k0Oy4AX3PwuBr33IhirytA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E836A805F76; Wed, 15 Mar 2023 16:59:13 +0000 (UTC) Received: from [10.22.34.146] (unknown [10.22.34.146]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3FE4B492B02; Wed, 15 Mar 2023 16:59:13 +0000 (UTC) Message-ID: Date: Wed, 15 Mar 2023 12:59:13 -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 0/5] cgroup/cpuset: Miscellaneous updates Content-Language: en-US To: Will Deacon Cc: Tejun Heo , Zefan Li , Johannes Weiner , Shuah Khan , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Peter Zijlstra References: <20230306200849.376804-1-longman@redhat.com> <20230315162436.GA19015@willie-the-truck> From: Waiman Long In-Reply-To: <20230315162436.GA19015@willie-the-truck> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/15/23 12:24, Will Deacon wrote: > Hi Waiman, > > On Mon, Mar 06, 2023 at 03:08:44PM -0500, Waiman Long wrote: >> This patch series includes miscellaneous update to the cpuset and its >> testing code. >> >> Patch 2 is actually a follow-up of commit 3fb906e7fabb ("cgroup/cpuset: >> Don't filter offline CPUs in cpuset_cpus_allowed() for top cpuset tasks"). >> >> Patches 3-4 are for handling corner cases when dealing with >> task_cpu_possible_mask(). > Thanks for cc'ing me on these. I ran my arm64 asymmetric tests and, fwiw, > I get the same results as vanilla -rc2, so that's good. > > One behaviour that persists (and which I thought might be addressed by this > series) is the following. Imagine a 4-CPU system with CPUs 0-1 being 64-bit > only. If I configure a parent cpuset with 'cpuset.cpus' of "0-2" and a > child cpuset with 'cpuset.cpus' of "0-1", then attaching a 32-bit task > to the child cpuset will result in an affinity mask of 4. If I then change > 'cpuset.cpus' of the parent cpuset to "0-1,3", the affinity mask of the > task remains at '4' whereas it might be nice to update it to '8', in-line > with the new affinity mask of the parent cpuset. > > Anyway, I'm not complaining (this is certainly _not_ a regression), but > I thought I'd highlight it in case you were aiming to address this with > your changes. I believe it is because changes in parent cpuset only won't cause the tasks in the child cpuset to be re-evaluated unless it causes a change in the effective_cpus of the child cpuset. This is the case here. We currently don't track how many tasks in the child cpusets are using parent's cpumask due to lacking runnable CPUs in the child cpuset. We can only fix this if we track those special tasks. It can be fixable, but I don't know if it is a problem that is worth fixing. Cheers, Longman