[lkml]   [2012]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH 0/2] More i387 state save/restore work

Ok, this is a series of two patches that continue my i387 state
save/restore series, but aren't necessarily worth it for Linux-3.3.

That said, the first one is a bug-fix - but it's an old bug, and I'm not
sure it can actually be triggered. The failure path for the FP state
preload is bogus - and always was. But I'm not sure it really *can* fail.

The first one has another small bugfix in it too, and I think that one may
be new to the rewritten FP state preloading - it doesn't update the
fpu_counter, so once it starts preloading, it never stops.

I wrote a silly FPU task switch testing program, which basically starts
two processes pinned to the same CPU, and then uses sched_yield() in both
to switch back-and-forth between them. *One* of the processes uses the FPU
between every yield, the other does not. It runs for two seconds, and
counts how many loops it gets through.

With that test, I get:

- Plain 3.3-rc4:

[torvalds@i5 ~]$ uname -r
[torvalds@i5 ~]$ ./a.out ;./a.out ;./a.out ;./a.out ;./a.out ;./a.out ;
2216090 loops in 2 seconds
2216922 loops in 2 seconds
2217148 loops in 2 seconds
2232191 loops in 2 seconds
2186203 loops in 2 seconds
2231614 loops in 2 seconds

- With the first patch that fixes the FPU preloading to eventually stop:

[torvalds@i5 ~]$ uname -r
[torvalds@i5 ~]$ ./a.out ;./a.out ;./a.out ;./a.out ;./a.out ;./a.out ;
2306667 loops in 2 seconds
2295760 loops in 2 seconds
2295494 loops in 2 seconds
2296282 loops in 2 seconds
2282229 loops in 2 seconds
2301842 loops in 2 seconds

- With the second patch that does the lazy preloading

[torvalds@i5 ~]$ uname -r
[torvalds@i5 ~]$ ./a.out ;./a.out ;./a.out ;./a.out ;./a.out ;./a.out ;
2466973 loops in 2 seconds
2456168 loops in 2 seconds
2449863 loops in 2 seconds
2461588 loops in 2 seconds
2478256 loops in 2 seconds
2476844 loops in 2 seconds

so these things do make some difference. But it is also interesting to see
from profiles just how expensive setting CR0.TS is (the write to CR0 is
very expensive indeed), so even when you avoid the FP state restore
lazily, just setting TS in between task switches is still a big cost of
FPU save/restore.

Linus Torvalds (2):
i387: use 'restore_fpu_checking()' directly in task switching code
i387: support lazy restore of FPU state

arch/x86/include/asm/i387.h | 48 +++++++++++++++++++++++++++----------
arch/x86/include/asm/processor.h | 3 +-
arch/x86/kernel/cpu/common.c | 2 +
arch/x86/kernel/process_32.c | 2 +-
arch/x86/kernel/process_64.c | 2 +-
arch/x86/kernel/traps.c | 40 ++++++-------------------------
6 files changed, 49 insertions(+), 48 deletions(-)

Comments? I feel confident enough about these that I thin kthey might even
work in 3.3, especially the first one. But I want people to look at



 \ /
  Last update: 2012-02-19 23:25    [W:0.126 / U:25.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site