[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54B549E2.3040303@redhat.com>
Date: Tue, 13 Jan 2015 11:37:54 -0500
From: Rik van Riel <riel@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
CC: linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
matt.fleming@...el.com, bp@...e.de, pbonzini@...hat.com,
tglx@...utronix.de, luto@...capital.net
Subject: Re: [RFC PATCH 03/11] x86,fpu: move __thread_fpu_begin to when the
task has the fpu
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/13/2015 10:24 AM, Oleg Nesterov wrote:
> On 01/11, riel@...hat.com wrote:
>>
>> --- a/arch/x86/include/asm/fpu-internal.h +++
>> b/arch/x86/include/asm/fpu-internal.h @@ -420,7 +420,6 @@ static
>> inline void switch_fpu_prepare(struct task_struct *old, struct
>> task_struc if (preload) { new->thread.fpu_counter++;
>> set_thread_flag(TIF_LOAD_FPU); - __thread_set_has_fpu(new);
>> prefetch(new->thread.fpu.state); } else if (!use_eager_fpu())
>> stts(); @@ -436,7 +435,6 @@ static inline void
>> switch_fpu_prepare(struct task_struct *old, struct task_struc
>> prefetch(new->thread.fpu.state); set_thread_flag(TIF_LOAD_FPU);
>> } - __thread_fpu_begin(new); } /* else: CR0.TS is still set
>> from a previous FPU switch */ } @@ -451,6 +449,7 @@ static inline
>> void switch_fpu_prepare(struct task_struct *old, struct
>> task_struc static inline void switch_fpu_finish(struct
>> task_struct *new) { if (test_and_clear_thread_flag(TIF_LOAD_FPU))
>> { + __thread_fpu_begin(new); if
>> (unlikely(restore_fpu_checking(new))) drop_init_fpu(new); }
>
> Then perhaps it makes sense to move fpu_lazy_restore() to
> fpu_finish() too ?
I do that later in the series. I would like to keep that in a
separate changeset, for bisecting reasons.
> Either way, afaics we do not need use_eager_fpu() before
> fpu_lazy_restore(), and this reminds me that every use_eager_fpu()
> check in switch_fpu_prepare() looks confusing.
Agreed. The patch that moves fpu_lazy_restore() into
switch_fpu_finish() also removes the use_eager_fpu()
condition for that.
Another reason for it to be by itself in its own
changeset :)
- --
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUtUniAAoJEM553pKExN6D1KkH/0jJaxlbXBWdx3XRx3KczPiH
DJzWhUanmEZzFdCuyK/V8zDI0OjDorOntTTrA3rg1StBYGYgAm3hPMiVB5YvDJ8e
8YeJ9R+5FhMxqgBSKLHIGOazOjYCCAbl/9F+uTDnkOlsyRvJiNAVuURFdeXeWPx9
2tr2PoTVyPZlfIzVHDZKke1aeN1nS5m8Dlww3Wi1NTNJaDiKcguIMvfFtMc8j6BG
NRezcbEr+4UfQbV/k6JbMdS79Svq3xg9gWNx5BRZtv6eh4ycC8BMIICSUFYh5LAm
HfCRvWZYN+mvykaGfxYnmONrdT2TXyivy0YOeyIbCOi0hx0q52XoNKA6JwBePeA=
=wEv+
-----END PGP SIGNATURE-----
--
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/
Powered by blists - more mailing lists