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.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 EDBC5C4742C for ; Thu, 29 Oct 2020 22:18:26 +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 74FBC20FC3 for ; Thu, 29 Oct 2020 22:18:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ewjl5Asj"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="vKeDxtJO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 74FBC20FC3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=+YGsySk/l8BmpmTJPL764R0Gz5q3FhusZDjYaOeiUyM=; b=ewjl5Asj4BSc/OZADSsCKPyuk Pg797ONZicn2c6EeZy1oJWjA2T/2xpjSjeAYpwfpzUpvqLP7ju66cfft5m/tIsJ5KydwUgHnaCEO0 BAlgBv6UecVpSoxfRlv8XoxxaFhk63kxUW6fX3OC+x0tXXWw/NTbSD7Qkx7tWtnukDf7ghkAk90sn TLfP4Ucym3Ot00uHpUvgC5L3d0kjmdLs5rVVz45z9UPA6IVn1iPgPj+/gD8YgXbZghNaKmLEv5sGF ZsD/kPfLaQngVD7viKKXz/BIuPT9T8HYOLkQ63tFptSghb34axGtGTEMFcy4yxA4HZBJ3kjx2KHCo mtkpaYfvg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kYGF2-0003B0-Ra; Thu, 29 Oct 2020 22:17:56 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kYGF0-0003AG-FA for linux-arm-kernel@lists.infradead.org; Thu, 29 Oct 2020 22:17:55 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 294F7206D5; Thu, 29 Oct 2020 22:17:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604009873; bh=Pij6QMvKVYRjcTFJa5YdnZpKOXzgnjsSh93wKob9L7o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vKeDxtJOi2600iX2U96eXwIe6mWxYoI6d2PhzR5pXLlSfvubfRT/RppOHAu27IIeX btnfcih952yxlEzoAIAKPyqsAkEuC6NyHO2/o9C+K8RVNmAATR+ni8bbc35mLhj2P+ Vl1v3shD4A9ywgoOIO0wMgakbICjZUVTMxQOxBKI= Date: Thu, 29 Oct 2020 22:17:48 +0000 From: Will Deacon To: Suren Baghdasaryan Subject: Re: [PATCH 0/6] An alternative series for asymmetric AArch32 systems Message-ID: <20201029221747.GC31375@willie-the-truck> References: <20201027215118.27003-1-will@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201029_181754_652315_27DC67AE X-CRM114-Status: GOOD ( 22.69 ) 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, Marc Zyngier , Peter Zijlstra , Catalin Marinas , Qais Yousef , Greg Kroah-Hartman , Elliott Hughes , kernel-team , 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 Hi Suren, On Thu, Oct 29, 2020 at 11:42:04AM -0700, Suren Baghdasaryan wrote: > On Tue, Oct 27, 2020 at 2:51 PM Will Deacon wrote: > > I was playing around with the asymmetric AArch32 RFCv2 from Qais: > > > > https://lore.kernel.org/r/20201021104611.2744565-1-qais.yousef@arm.com > > > > and ended up writing my own implementation this afternoon. I think it's > > smaller, simpler and easier to work with. In particular: > > > > * I got rid of the sysctl in favour of a plain cmdline parameter > > * I don't have a new CPU capability > > * I don't have a new thread flag > > * I expose a cpumask to userspace via sysfs to identify the 32-bit CPUs > > > > Anyway, I don't think we should merge this stuff (other than the first patch) > > until we've figured out what's going on in Android, but I wanted to get > > this out as something which we might be able to build on. > > Thanks for posting this series. Just to provide some more background, > on Android, 64-bit apps are forked from zygote64 process and 32-bit > ones from zygote. So normally we could handle the issues with such > asymmetric architectures using cpuset cgroup and placing zygote > process (and consequently all its children) in a separate cgroup with > affinity mask that includes only 32-bit capable cores. We would have > to take care of the affinity mask for such tasks during task > migrations, but it's still doable from userspace. However there are > 64-bit apps which fork 32-bit processes and that is the case which is > unclear how to handle without help from the kernel. Still discussing > possible solutions. CC'ing more people from Android to be in the loop. Thanks for joining in and adding others. Perhaps one thing we could do on top of this series is to restrict the affinity mask when execve()ing a 32-bit application. The major problem I have with that is that it goes directly against the man page for sched_setaffinity(), which states: | A child created via fork(2) inherits its parent's CPU affinity mask. | The affinity mask is preserved across an execve(2) so there's a risk of regression if applications rely on the mask being preserved. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel