Re: 2.5 or 2.4 kernel profiling

On Mon, Dec 11, 2000 at 09:27:18AM -0600, Brian Ford wrote:

I agree with you about the profiling stuff.  Did you post this idea to the
main kernel mailing list?

Sure; they were all too busy though.  Profiling already worked for most of
them, and a cross-architecture change either requires the co-operation of all
seperate architecture maintainers, or a dictatorial initiative from above.

Thanks.  I had already hacked something like this together.  It would be
great to finalize these and get them into the real sources.

Yes, that would be excellent.

I also turned checksumming off for testing purposes.  It helped some, but
I think my bottle neck is that I can't get the bus to run faster than 33
Mhz reliably.  If I could get the bus clocked at what it is rated, I might
be better off.

Absolutely; the bus is the bottleneck.  You'll find the network throughput
scales almost linearly with bus speed, so getting it clocked faster will give
a higher payback than more driver tweaking.  Also, doesn't the 8260 have
seperate memory subsystems to help get around this?

Regards,
Graham
--
Graham Stoney
Assistant Technology Manager
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Graham Stoney wrote:

Absolutely; the bus is the bottleneck.  You'll find the network throughput
scales almost linearly with bus speed,

I've never seen that.  My 860P with 80/40 MHz is faster than the
same processor at 50/50 MHz.  I also haven't seen the big speed
improvement using the DMA changes either.  I am experimenting with
a couple of other things, such as aligning the IP data on the
incoming side (i.e. misaligning the Ethernet frame).  Just using
bigger TCP window sizes will help more than anything else.

What tests were you using?  I have a variety of little things I
have written, but mostly use a source/sink TCP application.

.......  Also, doesn't the 8260 have
seperate memory subsystems to help get around this?

Yes, among other things.  The 8260 runs very well and I am currently
doing lots of performance testing on some custom boards.  I haven't
seen anything really bad in the driver yet, but there will likely be
some performance enhancements coming.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Tue, 12 Dec 2000, Graham Stoney wrote:

Also, doesn't the 8260 have seperate memory subsystems to help get
around this?

I assume you are referring to the local bus?  Well yes, but there are large
tradeoffs.

If you use the local bus for the receive buffers then you can have
simultaneous CPM to local bus and CPU to 60x bus transactions.  The catch
is that the local bus can not be cached.  So, you trade off bus contention
for caching/bursting.  The CPU must go across the 60x to local bus bridge
for those transactions.  The DMA engine can burst between the 60x and
local busses.

If the data has to end up in user space, it ends up being about a
wash, given the checksum and user space copy.  I need more testing to
confirm this, though.  If the user space copy was not needed, like for
routing, then it might help some.

--
Brian Ford
Software Engineer
Vital Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

At 09:26 AM 12/12/00 -0600, Brian Ford wrote:

On Tue, 12 Dec 2000, Graham Stoney wrote:

quoted

Also, doesn't the 8260 have seperate memory subsystems to help get
around this?

I assume you are referring to the local bus?  Well yes, but there are
large
tradeoffs.

If you use the local bus for the receive buffers then you can have
simultaneous CPM to local bus and CPU to 60x bus transactions.  The catch
is that the local bus can not be cached.  So, you trade off bus contention
for caching/bursting.  The CPU must go across the 60x to local bus bridge
for those transactions.  The DMA engine can burst between the 60x and
local busses.

If the data has to end up in user space, it ends up being about a
wash, given the checksum and user space copy.  I need more testing to
confirm this, though.  If the user space copy was not needed, like for
routing, then it might help some.

--
Brian Ford
Software Engineer
Vital Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

I've been known to be wrong in the past, and I could be missing an
assumption, but local bus memory is cachable, it just isn't
snoopable.  If you need snooping as a prerequisite for enabling cache,
that would make the local bus effectively uncachable.  It also is 32
bits wide (max) rather than 64 which will affect your bus bandwidth.

gvb


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/