Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1495031
| From | Dave Hansen <dave.hansen@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded |
| Date | 2016-10-03 22:10 +0200 |
| Message-ID | <sohIK-123-29@gated-at.bofh.it> (permalink) |
| References | <snzy1-5k2-3@gated-at.bofh.it> <snzy1-5k2-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 10/01/2016 01:31 PM, riel@redhat.com wrote:
> /*
> + * Check whether an FPU's register set is still loaded in the CPU.
> + */
> +static inline bool fpu_lazy_skip_restore(struct fpu *fpu)
> +{
> + bool still_loaded = (fpu->fpstate_active &&
> + fpu->last_cpu == raw_smp_processor_id() &&
> + __this_cpu_read(fpu_fpregs_owner_ctx) == fpu);
> +
> + fpu->fpregs_active = still_loaded;
> + return still_loaded;
> +}
I wonder if we should call this something more along the lines of
fpregs_activate_fast(), which returns if it managed to do the activation
fast or not. I _think_ that's more along the lines of what it is
actually doing. The fact that it can be lazy is really an
implementation detail.
What are the preempt rules with this thing? This needs to be called in
preempt-disabled contexts, right?
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded riel@redhat.com - 2016-10-01 23:00 +0200
Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded Dave Hansen <dave.hansen@linux.intel.com> - 2016-10-03 22:10 +0200
Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded Rik van Riel <riel@redhat.com> - 2016-10-03 22:30 +0200
Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded Dave Hansen <dave.hansen@linux.intel.com> - 2016-10-03 23:00 +0200
Re: [PATCH RFC 4/5] x86,fpu: lazily skip FPU restore when still loaded Rik van Riel <riel@redhat.com> - 2016-10-03 23:10 +0200
csiph-web