[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150116155445.GA7249@redhat.com>
Date: Fri, 16 Jan 2015 16:54:45 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Rik van Riel <riel@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Suresh Siddha <sbsiddha@...il.com>,
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: [PATCH 2/3] x86, fpu: don't abuse ->has_fpu in
__kernel_fpu_{begin,end}()
On 01/15, Rik van Riel wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/15/2015 02:20 PM, Oleg Nesterov wrote:
> > b/arch/x86/kernel/i387.c @@ -81,9 +81,7 @@ void
> > __kernel_fpu_begin(void) this_cpu_write(in_kernel_fpu, true);
> >
> > if (__thread_has_fpu(me)) { - __thread_clear_has_fpu(me);
>
> I will put that line back in the patch series that defers the
> loading of FPU state until the switch to user space,
I think this needs more discussion.
Firstly, __thread_clear_has_fpu() should go into __kernel_fpu_end(), it
should replace restore_fpu_checking().
But does your series actually need this change? Correctness-wise this is
not needed (afaics). Performance-wise I am not sure, kernel_fpu_begin()
is unlikely event. Plus I am not sure this is a win (in general), but I
can be easily wrong.
> but I
> guess we can go either way for now...
Yes, this should not really conflict with your changes in any case.
Given that you acked 1/3 and 3/3, perhaps you can ack this one as well?
Oleg.
--
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