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 0A3DBC388F9 for ; Wed, 21 Oct 2020 14:11:08 +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 8D42922249 for ; Wed, 21 Oct 2020 14:11:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wNR3zEZE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D42922249 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=dcKlureYqY1/Wj0fVme3PTTgkj2vAyUKM+jUoHJxKoI=; b=wNR3zEZEu4/i4PAtZo9jlYY5s vgA3odbPyeC/HfdhvVf5PCDlB6wFFXhRA7D0498/73cnLjJq/xz1S/XEIDxRudl5cb05RbyTsFrlb WIeT0Qf6oYX8sso5osPWqSid9RYmnZZNGlciYqx+qM3I1BQiMqNUb2GDyuGHX3v3TfBIMvvQB6/jA IBBVH2/xj19eNAKud5Q74Hh4NBqh7HW1TcVJKCObVU4NYDPJDDV2KvUzklnNjMjqDYE2Roxyu6nFw 1xgjYJ8KPRR8yhnsc9SxiuFZhw3RxNhu8vJFwyfpWYD4NQTF2q/bgVuqSh7gH4B7OQUVIltYcjV8J 22Vwmbe0w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVEoM-0002ei-NI; Wed, 21 Oct 2020 14:09:54 +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 1kVEoJ-0002dq-FI for linux-arm-kernel@lists.infradead.org; Wed, 21 Oct 2020 14:09:52 +0000 Received: from gaia (unknown [95.145.162.19]) (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 A79DB22249; Wed, 21 Oct 2020 14:09:48 +0000 (UTC) Date: Wed, 21 Oct 2020 15:09:46 +0100 From: Catalin Marinas To: Morten Rasmussen Subject: Re: [RFC PATCH v2 4/4] arm64: Export id_aar64fpr0 via sysfs Message-ID: <20201021140945.GD3976@gaia> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201021133316.GF8004@e123083-lin> 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-20201021_100951_846262_088E0617 X-CRM114-Status: GOOD ( 18.95 ) 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, "Peter Zijlstra \(Intel\)" , Marc Zyngier , Linus Torvalds , James Morse , Greg Kroah-Hartman , Will Deacon , 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: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). > 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. 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. 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(). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel