From: "H. Peter Anvin" <hpa@zytor.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Vincent Palatin <vpalatin@chromium.org>,
Ingo Molnar <mingo@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
the arch/x86 maintainers <x86@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
Duncan Laurie <dlaurie@chromium.org>,
Olof Johansson <olofj@chromium.org>
Subject: Re: [PATCH] x86, fpu: avoid FPU lazy restore after suspend
Date: Fri, 30 Nov 2012 11:38:25 -0800 [thread overview]
Message-ID: <50B90B31.3000907@zytor.com> (raw)
In-Reply-To: <CA+55aFz4M4GmQbUkD1dhTkLTYka4H+T_phrsXgx+eGe8g9iLYA@mail.gmail.com>
On 11/30/2012 11:25 AM, Linus Torvalds wrote:
>
> and in fact I think the right place to do this *might* be in
> "native_cpu_die()" instead, at which point it would actually be
> something like
>
> per_cpu(fpu_owner_task, cpu) = NULL;
>
> *after* the CPU is dead, so that nothing ever can actually see the
> state where a process is still running on the CPU and might possibly
> use the FPU.
>
> I dunno. I think doing it after really killing the CPU (ie in the
> native_cpu_die() function) might be easier to think about, but I don't
> really hate your patch either (it does make me go "ok, we need to
> guarantee no scheduling or FP use after" - which is probably true, but
> it's still some non-local thing). Either way, a comment about it and
> abstracting whatever the invalidation sequence is in fpu-internal.h
> sounds like a good idea.
>
Hmm... from my point of view it would almost seem saner to do this on
the way *up*... as part of CPU (re-)initialization. After all, the
"nothing is currently running on this CPU" is part of the initial state
of the CPU, regardless of if we have ever been online before or not.
-hpa
next prev parent reply other threads:[~2012-11-30 19:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 18:52 issue with x86 FPU state after suspend to ram Vincent Palatin
2012-11-30 18:52 ` [PATCH] x86, fpu: avoid FPU lazy restore after suspend Vincent Palatin
2012-11-30 18:57 ` H. Peter Anvin
2012-11-30 19:25 ` Linus Torvalds
2012-11-30 19:38 ` H. Peter Anvin [this message]
2012-11-30 19:41 ` Linus Torvalds
2012-11-30 19:51 ` H. Peter Anvin
[not found] ` <CAP_ceTxmMhQeDi=x9HmYke85hKMg3_YhbXSnfDC12rOcocQJpA@mail.gmail.com>
2012-11-30 19:55 ` H. Peter Anvin
2012-11-30 21:45 ` Vincent Palatin
2012-11-30 19:52 ` [PATCH v2] " Vincent Palatin
2012-11-30 20:15 ` [PATCH v3] " Vincent Palatin
2012-11-30 22:10 ` [tip:x86/urgent] x86, fpu: Avoid " tip-bot for Vincent Palatin
2012-11-30 19:26 ` tip-bot for Vincent Palatin
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=50B90B31.3000907@zytor.com \
--to=hpa@zytor.com \
--cc=a.p.zijlstra@chello.nl \
--cc=dlaurie@chromium.org \
--cc=jarkko.sakkinen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=olofj@chromium.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vpalatin@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.