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_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 BDA26C388F9 for ; Wed, 21 Oct 2020 14:43:11 +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 3ED122224E for ; Wed, 21 Oct 2020 14:43:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ni2g49o1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3ED122224E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.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=7Jr0VRtpdDIdnH2xXCBIv1dmiJB4Gd6z8tW7s6V20Yw=; b=ni2g49o1OAVh8OSnNd03vRrGE 6qCqoqMVD30VtHfOcwfSsKxj161/w7acy6k2CQ1rofL0yC5n26AdDum4jXLobZUA6G8IvWfM/2wGz WlOM5A24hXLz6Oey71vG7plYQhki8i2mWI8H6c30JpzdlbiX3EYU+li15W2Ui4YccV7YZ3LUgrrpU uziQL+GiVZOEqnUwDznNfEBCz/vdVx2C0j/XwPT1UCNa2AKzUeeYGqd/Sj46hv67w4JYPQuP03sx5 zEyCooiAriZXhw8QPKfOepQ8jx6zlGPFTerDBBVLozFC1sKANVuvMOVey8WyZ7Q1gEraVJBZ/0IAU EuJpmvsLw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVFJM-00070g-Md; Wed, 21 Oct 2020 14:41:56 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVFJJ-0006zT-NW for linux-arm-kernel@lists.infradead.org; Wed, 21 Oct 2020 14:41:54 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 10F47D6E; Wed, 21 Oct 2020 07:41:53 -0700 (PDT) Received: from e123083-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 938F83F66B; Wed, 21 Oct 2020 07:41:51 -0700 (PDT) Date: Wed, 21 Oct 2020 16:41:49 +0200 From: Morten Rasmussen To: Catalin Marinas Subject: Re: [RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs Message-ID: <20201021144149.GG8004@e123083-lin> References: <20201021104611.2744565-1-qais.yousef@arm.com> <20201021104611.2744565-5-qais.yousef@arm.com> <63fead90e91e08a1b173792b06995765@kernel.org> <20201021121559.GB3976@gaia> <20201021133316.GF8004@e123083-lin> <20201021140945.GD3976@gaia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201021140945.GD3976@gaia> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201021_104153_868710_2AAD8BA2 X-CRM114-Status: GOOD ( 25.75 ) 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, Will Deacon , "Peter Zijlstra \(Intel\)" , Greg Kroah-Hartman , James Morse , Marc Zyngier , Linus Torvalds , Qais Yousef , 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 Wed, Oct 21, 2020 at 03:09:46PM +0100, Catalin Marinas wrote: > On Wed, Oct 21, 2020 at 03:33:29PM +0200, Morten Rasmussen wrote: > > On Wed, Oct 21, 2020 at 01:15:59PM +0100, Catalin Marinas wrote: > > > one, though not as easy as automatic task placement by the scheduler (my > > > first preference, followed by the id_* regs and the aarch32 mask, though > > > not a strong preference for any). > > > > Automatic task placement by the scheduler would mean giving up the > > requirement that the user-space affinity mask must always be honoured. > > Is that on the table? > > I think Peter rejected it but I still find it a nicer interface from a > dumb application perspective. It may interact badly with cpusets though > (at least on Android). Agree that it would be nice for supporting legacy applications. Due to the cpuset interaction I think there is fair chance that user-space would want to know the aarch32 cpumask anyway though. > > > Killing aarch32 tasks with an empty intersection between the > > user-space mask and aarch32_mask is not really "automatic" and would > > require the aarch32 capability to be exposed anyway. > > I agree, especially if overriding the user mask is not desirable. But if > one doesn't play around with cpusets, 32-bit apps would run "fine" with > the scheduler transparently placing them on the correct CPU. Ruling out user-space setting affinity is another way of solving the problem ;-) > Anyway, if the task placement is entirely off the table, the next thing > is asking applications to set their own mask and kill them if they do > the wrong thing. Here I see two possibilities for killing an app: > > 1. When it ends up scheduled on a non-AArch32-capable CPU > > 2. If the user cpumask (bar the offline CPUs) is not a subset of the > aarch32_mask > > Option 1 is simpler but 2 would be slightly more consistent. I don't have strong preference. More consistent killing is probably nice for debugging purposes. If we go with 2, we would go round and kill all tasks in cpuset (both running and sleeping) if the cpuset mask was changed to not include aarch32 CPUs? > There's also the question on whether the kernel should allow an ELF32 to > be loaded (and potentially killed subsequently) if the user mask is not > correct on execve(). I wonder how many apps that would handle execve() failing? If we allow killing, the simplest solution if there is any doubt seems to be just to kill the task :-) Morten _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel