Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1206922rwl; Fri, 24 Mar 2023 07:36:39 -0700 (PDT) X-Google-Smtp-Source: AKy350YRaiH6EsTPabslGz1wihNdFyGtb6bXKHqEn7Gm/ifszj5KYFTlbow4yegBeMGteti2unnt X-Received: by 2002:a17:906:7243:b0:8f3:dc49:d8eb with SMTP id n3-20020a170906724300b008f3dc49d8ebmr2752013ejk.71.1679668599491; Fri, 24 Mar 2023 07:36:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679668599; cv=none; d=google.com; s=arc-20160816; b=Z1q8jtO1f0wHC0oAWoqec5izW346BIvOKh0b52nlbU2TFNvACaFVfqFLhzeqcyvTIa q+SNnWE4PaSHALyrTsRFWwi47Z91NHN2lfQWxtu5GxGAedaGS9rATlozSmxqicQ6p4jI FLWC78KURoeYtwylzedUwaD+YUDE2ioWF118hkK6/VJAbfyz1sLK2IggLHd17te6rybV RhFXHoyVeBF8XsL3QmLMS+opblqHD+oKggS/PjBbn+81ndBJ/gTjheGbBNPNGYlc/Ju1 adlolmdULPpi7hXMbXRclhnjAiHO4TB1Zss9oYyeB2YAogVyKvoreeIM31RLzB0rWHub YIXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=pks1Rocl7qfo9jMD7ZX/C3NcvitAOovHzQxGFFhxXpo=; b=XfsoRWt1nc6mqY5aIWMe9UNQQ3ikIbtE3UEWvAy6w8POt6IOqIeioM519Or0e7GK5B aG4DOaAF+ZqLtb3Cyx6k6gcRHp0gno7ysWbV8axyAr+uctiSWhozFsrGKpr6Bsk+L73i r4q02LiKn4zaqh//K/i3QZ22L5TeUrSvO8yCn63f7v9IRnb9lz82AIpAHx8vqi4/sfX3 3b3hg4QmSBMnysyBuFxA33JQLXT1G/B8JhHsRDEMpQkB/iI0dMwp58hjZCkdnLiHPxeX t72Nn4xyzffbEoPlLJMzQ6fpReo23eLdy4hMH8c3n14TS4bYXVR6zGcawT5Ln0LulE9I +nLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="TW4X/v31"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f3-20020a05640214c300b004af7e6911e7si47737edx.528.2023.03.24.07.36.15; Fri, 24 Mar 2023 07:36:39 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="TW4X/v31"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231298AbjCXOdD (ORCPT + 99 others); Fri, 24 Mar 2023 10:33:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229551AbjCXOdC (ORCPT ); Fri, 24 Mar 2023 10:33:02 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5EE1814235; Fri, 24 Mar 2023 07:33:01 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 0C17BCE2401; Fri, 24 Mar 2023 14:32:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45F8AC433EF; Fri, 24 Mar 2023 14:32:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679668377; bh=yxz8D2Zg0ZMCZt9HGM8J7hviWBLk56ggtJ1KZ+DkDGY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TW4X/v31+XvxigTPEeFIQrSpqf1C0wg34BEJL4Ewk0hehRrW2ZKZsQjnGXXStCEQp 5VkteDkPv+sdJn+wnCp00Q7ts0BXFvbvpUPoz/O9ozOkHdjO4LnSzaJvy2Lfehdi0r o0bbmMBhVD3QDLkFyY4APnSyWtyO3ymDaEdHiB8QpljXQXoAKlvYNlSVeZg+pwPPZe sPryW8AHtsYhf36NHIPB0QmnPAT7HBQXA41oQKclKF0ESgsa5b9KAsNfg7nYmJrsRX ucNevYIcTADp3ZgDhRMyA4mplhSlroJWECB9XeRhBSBgNHFndzP4dipMvgK5XNtnz6 OfNZPsFUIN1Wg== Date: Fri, 24 Mar 2023 14:32:50 +0000 From: Will Deacon To: Waiman Long Cc: Michal =?iso-8859-1?Q?Koutn=FD?= , Tejun Heo , Zefan Li , Johannes Weiner , Shuah Khan , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Peter Zijlstra Subject: Re: [PATCH 3/5] cgroup/cpuset: Find another usable CPU if none found in current cpuset Message-ID: <20230324143247.GA27199@willie-the-truck> References: <20230306200849.376804-1-longman@redhat.com> <20230306200849.376804-4-longman@redhat.com> <20230314181749.5b4k6selbgdhl3up@blackpad> <58a1a878-fa0b-285d-3e43-2b5103d3c770@redhat.com> <20230317122708.ax3m2d4zijkfdzjq@blackpad> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=unavailable 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 On Fri, Mar 17, 2023 at 10:59:26AM -0400, Waiman Long wrote: > On 3/17/23 08:27, Michal Koutn? wrote: > > On Tue, Mar 14, 2023 at 04:22:06PM -0400, Waiman Long wrote: > > > Some arm64 systems can have asymmetric CPUs where certain tasks are only > > > runnable on a selected subset of CPUs. > > Ah, I'm catching up. > > > > > This information is not captured in the cpuset. As a result, > > > task_cpu_possible_mask() may return a mask that have no overlap with > > > effective_cpus causing new_cpus to become empty. > > I can see that historically, there was an approach of terminating > > unaccomodable tasks: > > 94f9c00f6460 ("arm64: Remove logic to kill 32-bit tasks on 64-bit-only cores") > > the removal of killing had been made possible with > > df950811f4a8 ("arm64: Prevent offlining first CPU with 32-bit EL0 on mismatched system"). > > > > That gives two other alternatives to affinity modification: > > 2) kill such tasks (not unlike OOM upon memory.max reduction), > > 3) reject cpuset reduction (violates cgroup v2 delegation). > > > > What do you think about 2)? > > Yes, killing it is one possible solution. > > (3) doesn't work if the affinity change is due to hot cpu removal. So that > leaves this patch or (2) as the only alternative. I would like to hear what > Will and Tejun thinks about it. The main constraint from the Android side (the lucky ecosystem where these SoCs tend to show up) is that existing userspace (including 32-bit binaries) continues to function without modification. So approaches such as killing tasks or rejecting system calls tend not to work as well, since you inevitably get divergent behaviour leading to functional breakage rather than e.g. performance anomalies. Having said that, the behaviour we currently have in mainline seems to be alright, so please don't go out of your way to accomodate these SoCs. I'm mainly just concerned about introducing any regressions, which is why I ran my tests on this series Cheers, Will