>
> > Thinking 'hmm.. what is different when fpu_memcpy is in play?', I can
> > only come up with one thing; the exception (device_not_available) which
> > happens upon first use of the FPU after a context switch.
>
> If you change fstenv/fsave to fnstenv/fnsave, fpu_memcpy should run with
> SMP too. I'm using that for a long time, but I don't know why this makes
> a difference.
>
> Gerhard
>
Hi again Gerard,
That did cure the problem. The only thing I notice now, is that fpu
interrupts is climbing whereas previously (UP) it stayed at exactly 1.
CPU0
0: 40838 XT PIC timer
1: 910 XT PIC keyboard
2: 0 XT PIC cascade
5: 0 XT PIC soundblaster
8: 1 XT PIC rtc
10: 8 XT PIC NE2000
11: 5370 XT PIC aic7xxx
13: 185 XT PIC fpu
15: 5 XT PIC HiSax
NMI: 0
IPI: 0
If I run Bonnie with a filesize that it uses cache exclusively, I see
no increase in interrupts. As soon as it actually hits disk, there
is an increase of 2 at a minimum, increasing directly proportional
to the size of the test file. It seems to only happen when kswapd
kicks in.. which smells very funny.
I'm wondering if this is normal SMP behavior or a glitch in emulation.
Do you (or anyone else) see this on a real SMP machine?
Thanks again for the f->fn tip,
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu