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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 C3AA1C433E0 for ; Tue, 16 Feb 2021 10:35:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7B32464DCF for ; Tue, 16 Feb 2021 10:35:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229828AbhBPKfy (ORCPT ); Tue, 16 Feb 2021 05:35:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:60064 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229812AbhBPKfw (ORCPT ); Tue, 16 Feb 2021 05:35:52 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 98F0264E00; Tue, 16 Feb 2021 10:35:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613471711; bh=2W9VGlDi6NiRZ8mjUgWkcUO+fkrD9CT0ZH5lsbWfrEU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DXioZDTwzPDIlGSizhs8rWfUJYgS2Tuc+cqT64jvlfj5io8N1/9EA8f0M/fEqAYec NVlXcOi79+2xaXle0ruTahXbL6TVK6wMOB1ryXzPQQB0GmNBkoJQgEyLyAxcvO2Snb 81y8KWvP6O5S380MdroFj3g4PclQDrp0RLn2cyB0IUrdy4vIfpWOmS5OYOZQQS76El oBOrWlsnDNKSdBO0HoiUB9OUhaZlThamowPKwu4ZWpi91GzgOjGFheChSl2bWsX/Am XfglT+NOibIQbjCRGvb/qplT4XOfo1fQ++xh2lRQddEOxREimtlmhA7kW1QZFcivdQ kLQFmr+coLqbg== Received: by mail-ot1-f50.google.com with SMTP id v3so3417165ota.2; Tue, 16 Feb 2021 02:35:11 -0800 (PST) X-Gm-Message-State: AOAM530BEETGY2LLO3JItTsaYBcYSppWj6y1LtNSMJjStQjFYURe9cAB dJldha0xWck5eJOrp1I98ZlcHJ64xhOYX6Ipiu8= X-Google-Smtp-Source: ABdhPJyWByBh4t+YLoIidK425VY3U+5gCaJa9ZbH9+97hLCz2MlNfVj5MPl5EAFmD3PwVx1tR8IiZbqtvuOKMFZdzKk= X-Received: by 2002:a05:6830:1285:: with SMTP id z5mr14564809otp.90.1613471710852; Tue, 16 Feb 2021 02:35:10 -0800 (PST) MIME-Version: 1.0 References: <20201218170106.23280-1-ardb@kernel.org> In-Reply-To: From: Ard Biesheuvel Date: Tue, 16 Feb 2021 11:35:00 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/5] running kernel mode SIMD with softirqs disabled To: Peter Zijlstra Cc: Linux Crypto Mailing List , Linux ARM , Linux Kernel Mailing List , Dave Martin , Mark Brown , Herbert Xu , Eric Biggers , Will Deacon , Catalin Marinas , Thomas Gleixner , Sebastian Andrzej Siewior , Ingo Molnar Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, 16 Feb 2021 at 11:10, Peter Zijlstra wrote: > > On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote: > > [ TL;DR for the non-ARM folks on CC: disabling softirq processing when using > > SIMD in kernel mode could reduce complexity and improve performance, but we > > need to decide whether we can do this, and how much softirq processing > > latency we can tolerate. If we can find a satisfactory solution for this, > > we might do the same for x86 and 32-bit ARM as well. ] > > > - could we do the same on x86, now that kernel_fpu_begin/end is no longer > > expensive? > > Can't we simply save/restore the relevant register set? > > So something like (note amluto was wanting to add a regset argument): > > > kernel_fpu_begin(MMX) > > kernel_fpu_begin(SSE) > kernel_fpu_end(); > > ... > kernel_fpu_end() > > Would have to save the MMX regs on first SIRQ invocation of > kernel_fpu_begin(), and then have softirq context termination > above, restore it. > > I mean, we already do much the same for the first kernel_fpu_begin(), > that has to save the user registers, which will be restore when we go > back to userspace. > > So why not do exactly the same for softirq context? That is what we originally had on arm64, with per-CPU buffers of the appropriate size. This became a bit messy when SVE support was added, because the register file is so large (32 registers of up to 2048 bits each), and since the kernel does not use SVE itself, we want the inner per-CPU buffer to only cover 128 bits per register. This means we cannot allow the region above to interrupt the outer preserve (which is implemented entirely in software), since resuming the outer preserve after a sirq would preserve content that was corrupted by the inner preserve/restore. This could be addressed by disabling interrupts across the outer preserve, but this caused a problem somewhere else (Dave might remember the details better than I do). So we ended up making SIMD in task context mutually exclusive with SIMD in softirq context, also because that is what 32-bit ARM and x86 were already doing as well. But I understand that these concerns may not apply to x86 at all, so perhaps the answer there is indeed to have a alternate buffer. And actually, Andy L. suggested the same when I asked him about it on IRC. 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 72BAEC433E0 for ; Tue, 16 Feb 2021 10:37:10 +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 21C4C64DCF for ; Tue, 16 Feb 2021 10:37:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 21C4C64DCF 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: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=8r0MLScYVvxsIQxrPKvX9+KOsGrEARpKo4mpw8m2W8w=; b=qDrMSgs5Pk1graOBPx0YeR5jt 7fudqeJ7glhjWcl/58jpvbu8neaScjMGAMbyPVyZ5cCgh2eVGeCjpKc9hz34VMR1Zy9IwHKfrhgqD ZU5GHnn/TA0vnD1khWBDan2X6yvOS5vd0n+BJ/XeyPVHIb9fWCV6s4gXxFzw+P3ZEb65MPXGfaXX/ LOOBGyaxOIDuAbe9Isvbm1eAVzw8LLstnhD9JexGSGX7CnsM6z0gTgjbPvi6bzsxBWE3wm2sObqq2 yUVGmSLNBOZE3sGVweQlF0Qb8IvgXkaxKEthEuRsRV5ps7ARoQN4FRGd0Qg+IUzH3yRYc04rQYRBr T94fFoVOw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lBxhN-0000nG-G4; Tue, 16 Feb 2021 10:35:17 +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 1lBxhI-0000mV-Mh for linux-arm-kernel@lists.infradead.org; Tue, 16 Feb 2021 10:35:14 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id A5A2964E04 for ; Tue, 16 Feb 2021 10:35:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613471711; bh=2W9VGlDi6NiRZ8mjUgWkcUO+fkrD9CT0ZH5lsbWfrEU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DXioZDTwzPDIlGSizhs8rWfUJYgS2Tuc+cqT64jvlfj5io8N1/9EA8f0M/fEqAYec NVlXcOi79+2xaXle0ruTahXbL6TVK6wMOB1ryXzPQQB0GmNBkoJQgEyLyAxcvO2Snb 81y8KWvP6O5S380MdroFj3g4PclQDrp0RLn2cyB0IUrdy4vIfpWOmS5OYOZQQS76El oBOrWlsnDNKSdBO0HoiUB9OUhaZlThamowPKwu4ZWpi91GzgOjGFheChSl2bWsX/Am XfglT+NOibIQbjCRGvb/qplT4XOfo1fQ++xh2lRQddEOxREimtlmhA7kW1QZFcivdQ kLQFmr+coLqbg== Received: by mail-ot1-f54.google.com with SMTP id c16so8622903otp.0 for ; Tue, 16 Feb 2021 02:35:11 -0800 (PST) X-Gm-Message-State: AOAM531ev8Emnkx5JEZbffkxvJQyRU/ym00Uj+SpuEacEqyYSwLS5x4l bfgVkrpEgLvdbLYT5hwdTTRZEVTDH1HVn6ZJxqw= X-Google-Smtp-Source: ABdhPJyWByBh4t+YLoIidK425VY3U+5gCaJa9ZbH9+97hLCz2MlNfVj5MPl5EAFmD3PwVx1tR8IiZbqtvuOKMFZdzKk= X-Received: by 2002:a05:6830:1285:: with SMTP id z5mr14564809otp.90.1613471710852; Tue, 16 Feb 2021 02:35:10 -0800 (PST) MIME-Version: 1.0 References: <20201218170106.23280-1-ardb@kernel.org> In-Reply-To: From: Ard Biesheuvel Date: Tue, 16 Feb 2021 11:35:00 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 0/5] running kernel mode SIMD with softirqs disabled To: Peter Zijlstra X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210216_053512_970152_07008FA6 X-CRM114-Status: GOOD ( 24.96 ) 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: Herbert Xu , Catalin Marinas , Sebastian Andrzej Siewior , Linux Kernel Mailing List , Ingo Molnar , Eric Biggers , Mark Brown , Linux Crypto Mailing List , Thomas Gleixner , Will Deacon , Dave Martin , Linux ARM 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 Tue, 16 Feb 2021 at 11:10, Peter Zijlstra wrote: > > On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote: > > [ TL;DR for the non-ARM folks on CC: disabling softirq processing when using > > SIMD in kernel mode could reduce complexity and improve performance, but we > > need to decide whether we can do this, and how much softirq processing > > latency we can tolerate. If we can find a satisfactory solution for this, > > we might do the same for x86 and 32-bit ARM as well. ] > > > - could we do the same on x86, now that kernel_fpu_begin/end is no longer > > expensive? > > Can't we simply save/restore the relevant register set? > > So something like (note amluto was wanting to add a regset argument): > > > kernel_fpu_begin(MMX) > > kernel_fpu_begin(SSE) > kernel_fpu_end(); > > ... > kernel_fpu_end() > > Would have to save the MMX regs on first SIRQ invocation of > kernel_fpu_begin(), and then have softirq context termination > above, restore it. > > I mean, we already do much the same for the first kernel_fpu_begin(), > that has to save the user registers, which will be restore when we go > back to userspace. > > So why not do exactly the same for softirq context? That is what we originally had on arm64, with per-CPU buffers of the appropriate size. This became a bit messy when SVE support was added, because the register file is so large (32 registers of up to 2048 bits each), and since the kernel does not use SVE itself, we want the inner per-CPU buffer to only cover 128 bits per register. This means we cannot allow the region above to interrupt the outer preserve (which is implemented entirely in software), since resuming the outer preserve after a sirq would preserve content that was corrupted by the inner preserve/restore. This could be addressed by disabling interrupts across the outer preserve, but this caused a problem somewhere else (Dave might remember the details better than I do). So we ended up making SIMD in task context mutually exclusive with SIMD in softirq context, also because that is what 32-bit ARM and x86 were already doing as well. But I understand that these concerns may not apply to x86 at all, so perhaps the answer there is indeed to have a alternate buffer. And actually, Andy L. suggested the same when I asked him about it on IRC. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel