> You can do better that that. FXSR doesn't destroy the FPU contents; if
> you track the context carefully you can completely avoid the restore.
> This requires keeping a per-cpu variable that holds a pointer to the
to be honest, while I like the idea, it does scare me from a security
point of view, both in terms of leaks and in terms of injecting bad
stuff.
> > --- linux-2.6.17-sleazyfpu.orig/arch/x86_64/kernel/process.c
> > +++ linux-2.6.17-sleazyfpu/arch/x86_64/kernel/process.c
> > @@ -515,6 +515,9 @@ __switch_to(struct task_struct *prev_p,
> > int cpu = smp_processor_id();
> > struct tss_struct *tss = &per_cpu(init_tss, cpu);
> >
> > + /* prefetch the fxsave area into the cache */
> > + prefetch(&next->i387.fxsave);
> > +
> > /*
> > * Reload esp0, LDT and the page table pointer:
> > */
>
> This prefetch is probably a bad idea. I ported your patch to i386 and it was
> actually slower until I changed it:
>
> + if (next_p->fpu_counter > 5)
> + /* prefetch the fxsave area into the cache */
> + prefetch(&next->i387.fxsave);
> +
>
> Now it's ~.4% faster. The test was an FP program doing a simple benchmark
> while a non-FP program ran in a tight loop.
nice! I sort of am not a big fan of if .. prefetch() but if it shows
gain... then you convinced me. 0.4% is roughly the same order I saw.
It's not gigantic but it's almost free to do so it may be worth it
anyway...
Can you send me your patch so that I can integrate it (and I'll port
your if() to the prefetch)...
Greetings,
Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
