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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B41ADC64E7B for ; Tue, 1 Dec 2020 12:39:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3F2AE20757 for ; Tue, 1 Dec 2020 12:39:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="2e37DUQ/"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="V4UhIUVR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3F2AE20757 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wyR1+Y6QE77cNcFQ9+O7wcFbTZFveXpIcWNlnXycock=; b=2e37DUQ/zGFtujRg7GWr5RKR1 xODqaBD3jZoVk7XZnz1R1Ve3LH7Tf8+5EM5rdshlHKbDyIAPN8ivG+fI6wUOikkpXm404sOaHXHAw KOcPVpvg/VBUBDyOIpdbCz6FEf2485jNbhN4QOMKakicnT9LTXSflE70IsD0jl6BYlIJnfOM32nTb 209L08FCJEcSFDEGUCZHix5G54zIGAwmbmJgxQjL1FhR1wLxm3AI8l1jsmAD3cM700IOdnDlbImLy JUqDXoiyExDYT/pbyuTZ7Yeyj3ALZwRj6A4k778aW6V0+GsqkHfyGIzMSYY0Vvg4I7RHqRQDxeqcF RgBhrsM1A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kk4uq-0001ps-QM; Tue, 01 Dec 2020 12:37:56 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kk4un-0001p6-Uo for linux-arm-kernel@lists.infradead.org; Tue, 01 Dec 2020 12:37:54 +0000 Received: by mail-wm1-x344.google.com with SMTP id d3so2490987wmb.4 for ; Tue, 01 Dec 2020 04:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=lBUww53RFhoSaA4q+roaei0e4iCTcYgJXrbA2ztPW1s=; b=V4UhIUVR2V1Ts6TfWAjd3Xk02gdycLDzXgLKwUvsYOCK3WXCsjGTifjGfsUD2SLFr5 v4pdCtNjSfhH6lqdkxSv/sK+K3SmbVydOb/PHVBJYlIca6EzsIL1FsjlsyG3HTh3vNen G/YCDDpD9p9IIpIM6AnIAuwRylLQ6cJEDsLxkrZctPaFeW6MEx7eod3nzNbxaTsHIkMb CKgcLS0dtMfSwHNl2ewGNobaxAEU2+YFS8OvEF7vQhyhhMcrwP9EjvDRE6gmp3eXySOE yuISy+nLTfZ0p+NuMpsJI6/gYvhJSBN6FcOQMRaqbpyuOXXcKbgllp5u0gqe93rM78db GDfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=lBUww53RFhoSaA4q+roaei0e4iCTcYgJXrbA2ztPW1s=; b=Yfk5mdRQ8nVxOu62QikFY1rLfEA5UgT3C4AL6CsSYm/oAtpJ4/nnqUcfMis94VL56I p2nhyYHuZVnJxvcAbyid/9j1sQfxbYdFtUgzuUxwfLpNVDqeCybKt4I8gqkaSvSlR5rG S8V0Jq5FfGjrPYc5BP+T2/TF3jxL5U14vGVPpRbxHj1ztA2YLdy0kx7vF+QzGgKkUpOf eNdJ9kMYQtgZPoilE47wlulpKrWkyHYQS6tyYYGaLDA5Qb4c4/33W0gQFeZfVyIZxFFw 5ctQEfSpGGUUtMf+4/eCBMGgFDQXQ6YFvrX4dYY3y7GgNEZmipq58wsfVoXdECjUkcyV tWYg== X-Gm-Message-State: AOAM533JSUPactSeO+OWNpBchsRIpftmvrMJv2x1aDdzWyxbKxDHNeZE GRUBNEgE4PDh4HqdqeOdsygyLA== X-Google-Smtp-Source: ABdhPJxVMxM7zxrRtQ5ATPRAIFdYrni8gzqkoCgfysS6KtplDal1I2J1qZu15IQmmDN/O+Q++hoi5g== X-Received: by 2002:a7b:c05a:: with SMTP id u26mr2471062wmc.159.1606826272146; Tue, 01 Dec 2020 04:37:52 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:f693:9fff:fef4:a7ef]) by smtp.gmail.com with ESMTPSA id 21sm3147147wme.0.2020.12.01.04.37.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Dec 2020 04:37:51 -0800 (PST) Date: Tue, 1 Dec 2020 12:37:48 +0000 From: Quentin Perret To: Qais Yousef Subject: Re: [PATCH v4 09/14] cpuset: Don't use the cpu_possible_mask as a last resort for cgroup v1 Message-ID: <20201201123748.GA1896574@google.com> References: <20201124155039.13804-1-will@kernel.org> <20201124155039.13804-10-will@kernel.org> <20201127133245.4hbx65mo3zinawvo@e107158-lin.cambridge.arm.com> <20201130170531.qo67rai5lftskmk2@e107158-lin.cambridge.arm.com> <20201130173610.GA1715200@google.com> <20201201115842.t77abecneuesd5ih@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201201115842.t77abecneuesd5ih@e107158-lin.cambridge.arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201201_073754_101549_8113186D X-CRM114-Status: GOOD ( 36.04 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, Juri Lelli , kernel-team@android.com, Vincent Guittot , Greg Kroah-Hartman , Peter Zijlstra , Catalin Marinas , Johannes Weiner , linux-kernel@vger.kernel.org, Suren Baghdasaryan , Ingo Molnar , Li Zefan , Marc Zyngier , Tejun Heo , Will Deacon , Morten Rasmussen , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tuesday 01 Dec 2020 at 11:58:42 (+0000), Qais Yousef wrote: > On 11/30/20 17:36, Quentin Perret wrote: > > On Monday 30 Nov 2020 at 17:05:31 (+0000), Qais Yousef wrote: > > > I create 3 cpusets: 64bit, 32bit and mix. As the name indicates, 64bit contains > > > all 64bit-only cpus, 32bit contains 32bit-capable ones and mix has a mixture of > > > both. > > > > > > If I try to move my test binary to 64bit cpuset, it moves there and I see the > > > WARN_ON_ONCE() triggered. The task has attached to the new cpuset but > > > set_allowed_cpus_ptr() has failed and we end up with whatever affinity we had > > > previously. Breaking cpusets effectively. > > > > Right, and so does exec'ing from a 64 bit task into 32 bit executable > > from within a 64 bit-only cpuset :( . And there is nothing we can really > > True. The kernel can decide to kill the task or force detach it then, no? > Sending SIGKILL makes more sense. Yeah but again, we need this to work for existing apps. Just killing it basically means we have no support, so that doesn't work for the use case :/ > > do about it, we cannot fail the exec because we need this to work for > > existing apps, and there is no way the Android framework can know > > upfront. > > It knows upfront it has enabled asym aarch32. So it needs to make sure not to > create 'invalid' cpusets? Problem is, we _really_ don't want to keep a big CPU in the background cpuset just for that. And even if we did, we'd have to deal with hotplug. > > > > So the only thing we can do really is WARN() and proceed to ignore the > > cpuset, which is what this series does :/. It's not exactly pretty but I > > don't think we can do much better than that TBH, and it's the same thing > > for the example you brought up. Failing cpuset_can_attach() will not > > help, we can only WARN and proceed ... > > I think for cases where we can prevent userspace from doing something wrong, we > should. Like trying to attach to a cpuset that will result in an empty mask. > FWIW, it does something similar with deadline tasks. See task_can_attach(). > > Similarly for the case when userspace tries to modify the cpuset.cpus such that > a task will end up with empty cpumask. We now have the new case that some tasks > can only run on a subset of cpu_possible_mask. So the definition of empty > cpumask has gained an extra meaning. I see this differently, e.g. if you affine a task to a CPU and you hotunplug it, then the kernel falls back to the remaining online CPUs for that task. Not pretty, but it keeps things functional. I'm thinking a similar kind of support would be good enough here. But yes, this cpuset mess is the part of the series I hate most too. It's just not clear we have better solutions :/ > > > > Now, Android should be fine with that I think. We only need the kernel > > to implement a safe fallback mechanism when userspace gives > > contradictory commands, because we know there are edge cases userspace > > _cannot_ deal with correctly, but this fallback doesn't need to be > > highly optimized (at least for Android), but I'm happy to hear what > > others think. > > Why not go with our original patch that fixes affinity then in the arch code if > the task wakes up on the wrong cpu? It is much simpler approach IMO to achieve > the same thing. I personally had no issues with that patch, but as per Peter's original reply, that's "not going to happen". Will's proposal seems to go one step further and tries its best to honor the contract with userspace (by keeping the subset of the affinity mask, ...) when that can be done, so if that can be acceptable, then be it. But I'd still rather keep this simple if at all possible. It's just my opinion though :) Thanks, Quentin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel