linux-kernel - Re: [RFT PATCH v1 0/7] enable FPSIMD lazy save and restore for arm64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Sep 2013 17:16:22 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Jiang Liu <liuj97@...il.com>
Cc:	Will Deacon <Will.Deacon@....com>,
	Jiang Liu <jiang.liu@...wei.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFT PATCH v1 0/7] enable FPSIMD lazy save and restore for
 arm64

On Fri, Sep 27, 2013 at 04:20:15PM +0100, Jiang Liu wrote:
> 	The patchset actually includes three optimizations.
> 
> The first one uses PF_USED_MATH to track whether the thread has
> accessed FPSIMD registers since it has been created. If the thread
> hasn't accessed FPSIMD registers since it's birth, we don't need to
> save and restore FPSIMD context on thread context switching.

But for detecting whether a thread used the FP/SIMD registers, you need
to disable the FP at context switch and trap the initial access. That's
one of the main issues with lazy saving/restoring and sometimes it could
be less efficient.

> The second one uses a percpu variable to track the owner of the
> FPSIMD hardware. When switching a thread, if it's the owner of
> the FPSIMD hardware, we don't need to load FPSIMD registers again.
> This is useful when context switching between user thread and
> kernel(idle) threads.

fpsimd_thread_switch() checks whether it switches to/from kernel thread.
I think we could do a bit better and avoid restoring if returning to the
same user thread but without the need for disabling the FP on thread
switch. I'm happy to take this part if factored out of the lazy patches
(for the rest I'd like to see benchmarks).

> The third one disable access to FPSIMD registers when switching a
> thread. When the thread tries to access FPSIMD registers the first
> time since it has been switched in, an exception is raised and then
> we will load FPSIMD context onto hardware.
> 
> The overhead (penalty) of the first and second optimizations is
> relatively small, so we could always enable them.

How do you detect that a thread used fpsimd?

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/