[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171201180828.GN10595@n2100.armlinux.org.uk>
Date: Fri, 1 Dec 2017 18:08:28 +0000
From: Russell King - ARM Linux <linux@...linux.org.uk>
To: Dave Martin <Dave.Martin@....com>
Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Mark Rutland <mark.rutland@....com>,
linux-rt-users@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Catalin Marinas <catalin.marinas@....com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Will Deacon <will.deacon@....com>,
linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
tglx@...utronix.de, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RT] arm*: disable NEON in kernel mode
On Fri, Dec 01, 2017 at 05:58:45PM +0000, Dave Martin wrote:
> +1, at least for arm64. I don't see a really compelling reason for
> holding kernel-mode NEON around memory management now that we have a
> strict save-once-restore-lazily model.
>
> This may not work so well for arm though -- I haven't looked at that
> code for a while.
>
>
> If there is memory manamement in any core loop, you already lost
> the performance battle, and an extra
> kernel_neon_end()+kernel_neon_begin() may not be that catastrophic.
Remember that we don't permit context switches while kernel neon is
in use on ARM - if there's any possibility of scheduling to occur,
the get_cpu() in kernel_neon_begin() should trigger a schedule-while-
atomic warning.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
Powered by blists - more mailing lists