From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Neuling <mikey@neuling.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
anton@samba.org
Subject: Re: [PATCH 0/2] More i387 state save/restore work
Date: Thu, 01 Mar 2012 22:30:00 +1100 [thread overview]
Message-ID: <1330601400.11728.48.camel@pasglop> (raw)
In-Reply-To: <CA+55aFwc6u6Mr9iCMKM+MexfKso4tN7D2VdWpJpuT2saj0Pgfw@mail.gmail.com>
On Sun, 2012-02-19 at 17:11 -0800, Linus Torvalds wrote:
> Oh, and final comment - looking at the thing you pointed at, it looks
> much more adventurous than my x86 FP state thing.
Right, that's the main reason why I haven't merged it (yet...). I though
the added complexity and risk wasn't worth the added complexity and
risk.
But going half way there as you are doing definitely looks like a good
idea. I'll have a look when I'm done whacking the shit out of our
exception entry path :)
> I always save things unconditionally, so that I don't have to do the
> IPI or just in general care about the "oops, now I want things in
> memory, not in some random CPU FP state". So mine is just a "writeback
> cache", and only optimizes the reading things back: there is never any
> dirty state in the CPU except when the process is actively using it.
>
> That obviously does mean that I only optimize away the restore side,
> not the save side. But it's *way* simpler, and considering that I just
> spent almost a week trying to figure out FP state save bugs, simple is
> good.
On the other hand, you seem to support FP use from random kernel
contexts such as softirq, interrupts etc... while we don't (well not
with the "normal" APIs, obviously you can always turn all IRQs off and
manually enable & save restore but that's too nasty for words).
Cheers,
Ben.
next prev parent reply other threads:[~2012-03-01 11:30 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-19 22:23 [PATCH 0/2] More i387 state save/restore work Linus Torvalds
2012-02-19 22:26 ` [PATCH 1/2] i387: use 'restore_fpu_checking()' directly in task switching code Linus Torvalds
2012-02-19 22:37 ` [PATCH 2/2] i387: support lazy restore of FPU state Linus Torvalds
2012-02-19 22:44 ` H. Peter Anvin
2012-02-19 23:18 ` H. Peter Anvin
2012-02-19 23:56 ` Linus Torvalds
2012-02-20 7:51 ` Ingo Molnar
2012-02-20 0:53 ` [PATCH 0/2] More i387 state save/restore work Michael Neuling
2012-02-20 1:03 ` Linus Torvalds
2012-02-20 1:06 ` Linus Torvalds
2012-02-20 1:11 ` Linus Torvalds
2012-03-01 11:30 ` Benjamin Herrenschmidt [this message]
2012-02-20 2:09 ` Indan Zupancic
2012-02-20 19:46 ` [PATCH v2 0/3] " Linus Torvalds
2012-02-20 19:47 ` [PATCH v2 1/3] i387: fix up some fpu_counter confusion Linus Torvalds
2012-02-20 19:48 ` [PATCH v2 2/3] i387: use 'restore_fpu_checking()' directly in task switching code Linus Torvalds
2012-02-20 19:48 ` [PATCH v2 3/3] i387: support lazy restore of FPU state Linus Torvalds
2012-02-21 1:50 ` Josh Boyer
2012-02-21 2:10 ` Linus Torvalds
2012-02-21 2:14 ` H. Peter Anvin
2012-02-21 5:27 ` Linus Torvalds
2012-02-21 5:35 ` H. Peter Anvin
2012-02-21 14:19 ` Josh Boyer
2012-02-21 17:59 ` H. Peter Anvin
2012-02-21 18:06 ` Ingo Molnar
2012-02-21 18:26 ` Linus Torvalds
2012-02-21 21:14 ` H. Peter Anvin
2012-02-21 21:39 ` [PATCH 0/2] i387: FP state interface cleanups Linus Torvalds
2012-02-21 21:40 ` [PATCH 1/2] i387: uninline the generic FP helpers that we expose to kernel modules Linus Torvalds
2012-02-21 21:41 ` [PATCH 2/2] i387: split up <asm/i387.h> into exported and internal interfaces Linus Torvalds
2012-02-21 23:50 ` [tip:x86/fpu] i387: Split " tip-bot for Linus Torvalds
2012-02-28 11:21 ` [PATCH 2/2] i387: split " Avi Kivity
2012-02-28 16:05 ` Linus Torvalds
2012-02-28 17:21 ` Avi Kivity
2012-02-28 17:37 ` Linus Torvalds
2012-02-28 18:08 ` Linus Torvalds
2012-02-28 18:29 ` Avi Kivity
2012-02-28 18:09 ` Avi Kivity
2012-02-28 18:34 ` Linus Torvalds
2012-02-28 19:06 ` Avi Kivity
2012-02-28 19:26 ` Linus Torvalds
2012-02-28 19:45 ` Avi Kivity
2012-02-21 23:49 ` [tip:x86/fpu] i387: Uninline the generic FP helpers that we expose to kernel modules tip-bot for Linus Torvalds
2012-02-21 2:18 ` [PATCH v2 3/3] i387: support lazy restore of FPU state Linus Torvalds
2012-02-21 2:32 ` H. Peter Anvin
2012-02-21 2:11 ` H. Peter Anvin
2012-02-21 21:54 ` Suresh Siddha
2012-02-21 21:57 ` Linus Torvalds
2012-02-21 22:19 ` Suresh Siddha
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=1330601400.11728.48.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=anton@samba.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikey@neuling.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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).