[Trac #905] The libertas driver causes a 33% slowdown.

[Zarro Boogs per Child]

#905: The libertas driver causes a 33% slowdown.
---------------------+------------------------------------------------------
 Reporter:  cjb      |        Owner:  marcelo
     Type:  defect   |       Status:  new    
 Priority:  blocker  |    Milestone:  BTest-3
Component:  kernel   |   Resolution:         
 Keywords:           |  
---------------------+------------------------------------------------------
Comment (by wmb at firmworks.com):

 The pystone test illustrates the problem, but since it is complicated, it
 is of limited value for fault isolation.  The following test illustrates
 the problem and is much simpler:

 bash-3.1# wget http://dev.laptop.org/~wmb/spin.zip
 bash-3.1# unzip spin.zip
 bash-3.1# time ./forth spin.fth

 real  0m9.234s
 user  0m9.210s
 sys   0m0.030s
 bash-3.1# mv /lib/firmware/usb8388.bin /lib/firmware/usb8388.bin.bak
 bash-3.1# rmmod usb8xxx
 bash-3.1# time ./forth spin.fth

 real  0m6.954s
 user  0m6.930s
 sys   0m0.020s
 bash-3.1#

 Notes:

 spin.fth contains:

 code spin
    cx pop
    begin loopne
 c;
 d# 500,000,000 spin

 It essentially consists of 500,000,000 iterations of a 1-instruction
 "decrement cx and branch to self" loop, i.e. the LOOPNE instruction.

 I have measured the runtime of this same loop under Open Firmware with
 interrupts turned off, using a stopwatch.  The result was the same - 6.9
 seconds.  So the "fast" time under Linux really means "essentially no
 overhead".

 This loop does not use memory at all.  The instruction just sits there
 decrementing the register.  It might not even hit the icache, depending on
 how the Geode's pipeline is implemented.

 Note also that the "user" and "real" times are virtually identical.  The
 2.4 second difference appears in the "user" category, so whatever it is
 that is causing the slowdown is getting charged against userland.  How
 does "time" account for time spent in interrupt handlers?  Is that charged
 to the running process, or to the system?  If interrupt time is charged to
 the system, it would imply that the slowdown is caused by some deep
 hardware stall instead of by time stolen by interrupt handlers.

-- 
Ticket URL: <http://dev.laptop.org/ticket/905#comment:1>
One Laptop Per Child <http://laptop.org/>