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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A3ED4C433F5 for ; Mon, 7 Mar 2022 20:57:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=eTA6fPwByfS9eqvc0oJeE9bkCCeHBH2WlHt5IIEb0i8=; b=WYG3onqRMji1aB ygejIcnH7kgcytqTZJOz1Hig7sbXRCmAeGsFq42jWlwr0xPCYEdSiAYCjJ/f2PNtGmRYQ1K4HFLf1 kABUEVyyztH8R5lI2LMLsUQg+wwwnK80anh1s0Q1fKj88XaACr7tCv2x1DZDPivhRS6qm1P7TEKFK oFdADtzHHgWNnuu1+3K8NUhttda2A7o2yIpwVn1EvXWwcaf4jdAaBg1u1HzIwoVwE9sCSpRrcixUR C9SA16h7WnlNq7Hdah6Lh2cdsc2fo949lwP1m7QSuBGi1o6xQDGOMAk3xsIsbn5YVs/xF7MW06GaM X4ANsJlPy7ZtdvMjPgVg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRKOy-001ZH4-15; Mon, 07 Mar 2022 20:56:20 +0000 Received: from mail-ua1-x932.google.com ([2607:f8b0:4864:20::932]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRKOQ-001Yst-Qg for linux-arm-kernel@lists.infradead.org; Mon, 07 Mar 2022 20:55:48 +0000 Received: by mail-ua1-x932.google.com with SMTP id k5so7073690uao.2 for ; Mon, 07 Mar 2022 12:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3efx4I6ECqH81aCU3YPkpCGQiAl11JZ+B3l3/G4I0GQ=; b=KJ6/0snALp/QPIjSmV7/OhFFmpPMZHy/pXxBV3i/iuPeXf78cjdV95uG8b4PfAHLfl 5/etfQRDIIRRywX8Ay7/DTiAzcnT4REbvdJ3OphAay1nk7/1Vb+o8gzbM4/JceeXIsoo Zxq0DDL6ctsiWr8R6GFcw0PlVZXOgBScYJkDE3c2bs+zHrMd28WLX/Ci5XSaP69Wix4P JUIa3Rp4sapduqI7KHjrVWPhkYrz4kut8CuW08REC2A9HZfVNY8yAenXcLnp9qxZOdZk oLisjGBAUxm/DM5z/vIxpG3GgFHIINbItahy3+WquHdlSmJBovlxCpKcjv/VkhmZMOL6 BZVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3efx4I6ECqH81aCU3YPkpCGQiAl11JZ+B3l3/G4I0GQ=; b=KyXhZErQYj8oaJG7PnAlKKTMtwDgoZRulvIa7BZbb3mrAzIDnEn6kA4Crt0r0qThwn +6gRwQwBpBjsBIpB7kQwgk1EKkP+bSF0KSkeAm29Xs6CSxXTPZS6/tWIehsXLXibTF18 BHZ8cNG8XQosXH7mBzIuLIAMxruVImTroZLhbZjeaIEOIWzEunF6ZHkKefkpTq8Rm4Et oaECAGypxxYOc6Uf9nRClthhBUihAIbYJjfKhgQeolGCe46w6d7QgyJzm1wEF7BYG6tw WKVhLHdGPEVqK14us1oUgLN0CvbkofWSweFnHVn5rSvMwgMbmqPqh95+m2dFH75WUbw/ CDSw== X-Gm-Message-State: AOAM532sQgiKx498AY6DbDF+N80vQv4TOgidAD3DEyVabvxnRJEOlhy6 9488pUGJ0Qj6UiX+lgw4XgUll1H0pSW8cImkqngQfQ== X-Google-Smtp-Source: ABdhPJxx2S9CVMEBlYwuXT9lK2EGQadQNAV2NVGtbrBX3GxrQttk3YjcRwDPNvffHuiTOGfHQoFpn8cKxEGqmkuUUaA= X-Received: by 2002:ab0:24c6:0:b0:34a:4141:5da4 with SMTP id k6-20020ab024c6000000b0034a41415da4mr5003702uan.16.1646686542137; Mon, 07 Mar 2022 12:55:42 -0800 (PST) MIME-Version: 1.0 References: <20220127195712.748150-5-broonie@kernel.org> In-Reply-To: From: Peter Collingbourne Date: Mon, 7 Mar 2022 12:55:31 -0800 Message-ID: Subject: Re: [PATCH v1 4/4] arm64/mte: Add userspace interface for enabling asymmetric mode To: Mark Brown Cc: Catalin Marinas , Szabolcs Nagy , Evgenii Stepanov , Will Deacon , Joey Gouly , Branislav Rankov , Linux ARM X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220307_125546_949204_BB657BBF X-CRM114-Status: GOOD ( 38.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Mon, Mar 7, 2022 at 11:10 AM Mark Brown wrote: > > On Mon, Mar 07, 2022 at 03:36:52PM +0000, Catalin Marinas wrote: > > On Fri, Mar 04, 2022 at 01:09:00PM -0800, Peter Collingbourne wrote: > > > > And an attempt to guess the user intent from which > > > bits are set seems prone to failure and unnecessarily restrictive. > > > > Only allowing asymmetric mode if both symmetric and async are supported > > is not that confusing. The only downside is that one cannot ask for > > asymmetric mode only but is this such a big problem? For testing one can > > always set the sysfs preferred mode to asymm. It will be some time > > before we see asymm in production. > > People like to do things like run their testsuites in containers and > generally not as root which is a problem for any interface that relies > on fiddling with the system settings. It's something people can work > around but it's not great. > > Another option here would be to just not expose asymmetric mode directly > via the pcrtl() at all and just allow it if it's supported and both > sync and async are enabled. Userspace ought to be able to tolerate > this since the preferred mode may vary depending on which CPU the task > gets scheduled on so the application may get a mix of modes if it's > requested both and it won't be able to worry about requesting async mode > since the option simply isn't there meaning it's less likely to get > specific coverage in application testsuites. > > > > The only downside that I've seen mentioned is that we will end up > > > issuing more syscalls on process startup which could harm performance. > > > I don't think that's the only downside. It's an ABI change as well > > w.r.t. getting the current TCF setting and asymm being invisible to an > > unaware app. The only way out I see is to make asymm a kernel choice > > when both sync and async are selected (potentially with another bit to > > opt it but without changing the TCF mask). > > It's not the most lovely API but given that we're faced with choices of > what to break or bodge another kludge would be to require that a second > bit be set when enabling asymmetric mode with that bit reading as zero. > That would break old code doing a save/restore flow though so while it > helps the original problem I don't know that it's actually doing much > overall. I think this just comes down to a question of where we end up > causing problems. I agree with Mark that there are going to be (to some extent hypothetical) compatibility problems no matter what we do. I think a good way to think about it is: if we need to do the same thing again in the future (in this case, adding another mode), which design would allow us to avoid the same potential compatibility problems? To me the PR_GET_TCF/PR_SET_TCF control seems like the best way of avoiding that. Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel