[lkml]   [1998]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: GRR!! SMP=1 sucks
>>> = Alan Cox
>> = Adam Richter
> = Alan Cox
>>>SMP=1 is upto 10% slower for single CPU
>>>on real tasks and 40% slower on certain FPU/sleep/FPU/sleep patterns
>> Is this situation permanent or just a matter of some tuning
>> needing to be done (e.g, the granularity of some locks needing to be
>> adjusted)? I would hope, for example, that spin locks to do not
>> actually "spin" if there is only one CPU.

>Permanent. The FPU lazy restore doesnt work SMP

I've looked at the arch/i386/kernel/traps.c code, and it looks
like it should be easy to change the "ifdef SMP" checks to "if SMP is
defined and smp_num_cpus > 1", and also to do lazy restores (but not
lazy saves) in the real SMP situations.

I was thinking of changing last_task_used_math into an array
with an element for each processor, but then I thought about the cache
contention that would result since multiple elements of this array
would be bigger than a (32 byte?) cache line. Does anybody know of an
array in the kernel for storing miscellaneous per-cpu data? If not, I
guess I'll create one to hold last_task_used math and the per-CPU stuff
from <linux/kernel_stat.h>, which probably has similar unnecessary
cache contention.

Anyhow, I don't see any fundamental problem that would make
the lazy FPU restore problem permanent.

Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205 \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:42    [W:0.023 / U:2.540 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site