From: Oleg Nesterov <oleg@redhat.com>
To: Rik van Riel <riel@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Suresh Siddha <sbsiddha@gmail.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
matt.fleming@intel.com, bp@suse.de, pbonzini@redhat.com,
tglx@linutronix.de, luto@amacapital.net
Subject: [PATCH 0/3] x86, fpu: more eagerfpu cleanups
Date: Mon, 19 Jan 2015 19:51:09 +0100 [thread overview]
Message-ID: <20150119185109.GA16427@redhat.com> (raw)
In-Reply-To: <20150115191918.GA27332@redhat.com>
On 01/15, Oleg Nesterov wrote:
>
> Let me send initial kernel_fpu_begin/end cleanups, I believe they make
> sense anyway and won't conflict with your changes.
>
> This is actually resend, I sent more patches some time ago but they were
> ignored.
>
> Note that (I hope) we can do more changes on top of this series, in
> particular:
>
> - remove all checks from irq_fpu_usable() except in_kernel_fpu
>
> - do not abuse FPU in kernel threads, this makes sense even if
> use_eager_fpu(), and with or without the changes you proposed.
On top of this series.
Initially I was going to make more changes, but then I decided to delay
the cleanups. IMHO this code needs them in any case. math_state_restore()
and its usage doesn't look nice. init_fpu() too, and unlazy_fpu(current)
is simply wrong afaics. Fortunately the only caller of init_fpu(current)
is coredump, so this task can't return to user-mode, still this doesn't
look good. And it should be unified with save_init_fpu(). Which has the
wrong WARN_ON_ONCE(!__thread_has_fpu(tsk)).
And I am not sure that unlazy_fpu() is correct wrt __kernel_fpu_begin(),
but probably this is because I do not know how fpu works. If the nested
__save_init_fpu() is fine, then why (before the previous changes)
__kernel_fpu_begin() does __thread_clear_has_fpu() first?
Rik, to remind, I think that your changes need 1 + 2 at least, to avoid
the performance regression. Perhaps this needs a single patch.
3/3 is not strictly neccessary, but imo it makes sense anyway, even
without your changes. And if we add TIF_LOAD_FPU, it would be nice to
filter out kthreads automatically.
Could someone review this series?
If this makes any sense, I'll try to make the cleanups later.
Oleg.
next prev parent reply other threads:[~2015-01-19 18:52 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-11 21:46 [RFC PATCH 0/11 BROKEN] move FPU context loading to userspace switch riel
2015-01-11 21:46 ` [RFC PATCH 01/11] x86,fpu: document the data structures a little riel
2015-01-12 21:18 ` Borislav Petkov
2015-01-12 21:38 ` Rik van Riel
2015-01-12 21:52 ` Dave Hansen
2015-01-13 15:59 ` Rik van Riel
2015-01-11 21:46 ` [RFC PATCH 02/11] x86,fpu: replace fpu_switch_t with a thread flag riel
2015-01-13 15:24 ` Oleg Nesterov
2015-01-13 16:35 ` Rik van Riel
2015-01-13 16:55 ` Oleg Nesterov
2015-01-11 21:46 ` [RFC PATCH 03/11] x86,fpu: move __thread_fpu_begin to when the task has the fpu riel
2015-01-13 15:24 ` Oleg Nesterov
2015-01-13 16:37 ` Rik van Riel
2015-01-11 21:46 ` [RFC PATCH 04/11] x86,fpu: defer FPU restore until return to userspace riel
2015-01-13 15:53 ` Oleg Nesterov
2015-01-13 17:07 ` Andy Lutomirski
2015-01-13 17:11 ` Oleg Nesterov
2015-01-13 17:18 ` Andy Lutomirski
2015-01-13 17:44 ` Rik van Riel
2015-01-13 17:57 ` Andy Lutomirski
2015-01-13 18:13 ` Rik van Riel
2015-01-13 18:26 ` Andy Lutomirski
2015-01-13 17:54 ` Rik van Riel
2015-01-13 18:22 ` Oleg Nesterov
2015-01-13 18:30 ` Oleg Nesterov
2015-01-13 20:06 ` Rik van Riel
2015-01-14 17:56 ` Oleg Nesterov
2015-01-13 17:58 ` Oleg Nesterov
2015-01-13 19:32 ` Rik van Riel
2015-01-11 21:46 ` [RFC PATCH 05/11] x86,fpu: ensure FPU state is reloaded from memory if task is traced riel
2015-01-13 16:19 ` Oleg Nesterov
2015-01-13 16:33 ` Rik van Riel
2015-01-13 16:50 ` Oleg Nesterov
2015-01-13 16:57 ` Rik van Riel
2015-01-11 21:46 ` [RFC PATCH 06/11] x86,fpu: lazily skip fpu restore with eager fpu mode, too riel
2015-01-13 17:11 ` Andy Lutomirski
2015-01-13 20:43 ` Rik van Riel
2015-01-14 18:36 ` Oleg Nesterov
2015-01-15 2:49 ` Rik van Riel
2015-01-15 19:34 ` Oleg Nesterov
2015-01-11 21:46 ` [RFC PATCH 07/11] x86,fpu: store current fpu pointer, instead of fpu_owner_task riel
2015-01-11 21:46 ` [RFC PATCH 08/11] x86,fpu: restore user FPU state lazily after __kernel_fpu_end riel
2015-01-14 18:43 ` Oleg Nesterov
2015-01-14 19:08 ` Oleg Nesterov
2015-01-11 21:46 ` [RFC PATCH 09/11] x86,fpu,kvm: keep vcpu FPU active as long as it is resident riel
2015-01-11 21:46 ` [RFC PATCH 10/11] x86,fpu: fix fpu_copy to deal with not-loaded fpu riel
2015-01-11 21:46 ` [RFC PATCH 11/11] (BROKEN) x86,fpu: broken signal handler stack setup riel
2015-01-15 19:19 ` [PATCH 0/3] x86, fpu: kernel_fpu_begin/end initial cleanups/fix Oleg Nesterov
2015-01-15 19:19 ` [PATCH 1/3] x86, fpu: introduce per-cpu "bool in_kernel_fpu" Oleg Nesterov
2015-01-16 2:22 ` Rik van Riel
2015-01-20 12:54 ` [tip:x86/fpu] x86, fpu: Introduce per-cpu in_kernel_fpu state tip-bot for Oleg Nesterov
2015-01-15 19:20 ` [PATCH 2/3] x86, fpu: don't abuse ->has_fpu in __kernel_fpu_{begin,end}() Oleg Nesterov
2015-01-16 2:27 ` Rik van Riel
2015-01-16 15:54 ` Oleg Nesterov
2015-01-16 16:07 ` Rik van Riel
2015-01-20 12:55 ` [tip:x86/fpu] x86, fpu: Don't abuse has_fpu in __kernel_fpu_begin /end() tip-bot for Oleg Nesterov
2015-01-15 19:20 ` [PATCH 3/3] x86, fpu: fix math_state_restore() race with kernel_fpu_begin() Oleg Nesterov
2015-01-16 2:30 ` Rik van Riel
2015-01-16 16:03 ` Oleg Nesterov
2015-01-20 12:55 ` [tip:x86/fpu] x86, fpu: Fix " tip-bot for Oleg Nesterov
2015-01-19 18:51 ` Oleg Nesterov [this message]
2015-01-19 18:51 ` [PATCH 1/3] x86, fpu: __kernel_fpu_begin() should clear fpu_owner_task even if use_eager_fpu() Oleg Nesterov
2015-01-20 14:15 ` Rik van Riel
2015-02-20 18:13 ` Borislav Petkov
2015-03-03 11:27 ` [tip:x86/fpu] x86/fpu: " tip-bot for Oleg Nesterov
2015-01-19 18:51 ` [PATCH 2/3] x86, fpu: always allow FPU in interrupt " Oleg Nesterov
2015-01-20 14:46 ` Rik van Riel
2015-01-20 22:46 ` Andy Lutomirski
2015-02-20 21:48 ` Borislav Petkov
2015-03-03 11:28 ` [tip:x86/fpu] x86/fpu: Always " tip-bot for Oleg Nesterov
2015-01-19 18:52 ` [PATCH 3/3] x86, fpu: don't abuse FPU in kernel threads " Oleg Nesterov
2015-01-20 14:53 ` Rik van Riel
2015-02-23 15:31 ` Borislav Petkov
2015-03-03 11:28 ` [tip:x86/fpu] x86/fpu: Don' t " tip-bot for Oleg Nesterov
2015-02-20 12:10 ` [PATCH 0/3] x86, fpu: more eagerfpu cleanups Borislav Petkov
2015-02-20 13:30 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150119185109.GA16427@redhat.com \
--to=oleg@redhat.com \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=matt.fleming@intel.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=riel@redhat.com \
--cc=sbsiddha@gmail.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).