Re: oprofiling is much saner looking now with rc6-smoketest

[Rick Jones <rick.jones2@hp.com>]

>> If this is inbound, and there is just plain checksumming and not anything
>> funny from conntrack, I would have expected checksum to be much larger than
>> copy.  Checksum (in the inbound direction) will take the cache misses and
>> the copy would not.  Unless... the data cache of the processor is getting
>> completely trashed - say from the netserver running on the router not
>> keeping up with the inbound data fully and so the copy gets "far away" from
>> the checksum verification.
>
> 220Mbit isn't good enough for ya? Previous tests ran at about 140Mbit, but due
> to some major optimizations by felix to fix a bunch of mis-alignment
> issues. Through the router, I've seen 260Mbit - which is perilously
> close to the speed that I can drive it at from the test boxes.

It is all a question of context.  The last time I was in a context where 
220 Mbit/s was high speed was when 100 BT first shipped or perhaps FDDI 
before that :)

>> Does perf/perf_events (whatever the followon to perfmon2 is called) have
>> support for the CPU used in the device?  (Assuming it even has a PMU to be
>> queried in the first place)
>
> Yes. Don't think it's enabled. It is running flat out, according to top.

Well, flat-out as far as the basic OS utilities can tell.  Stalled 
hardware manifests as CPU time consumed in something like top even 
though the processor may be sitting "idle," (in its context) twiddling 
its thumbs waiting on cache misses.  Hence the question about PMU support.

rick jones