> On Tue, Jan 22, 2008 at 02:35:21PM +0100, rubisher wrote: > > Btw, a while back, I dream to use relayfs to grab debug info. > > (<http://lists.parisc-linux.org/pipermail/parisc-linux/2006-April/053237.html>) > > > > Somebody else write it: > > <http://lkml.org/lkml/2007/11/13/208> > > > > Obviously, I have to instrument things manually but I test it succesfully. > > Here is already some primarily data test: > > [snip] > > :1201001199222127606:ccio_map_single_1:ccio_map_single() 0x1eb91896 -> > > 0x63b4896 size: 0x1000 > > :1201001199222203288:ccio_map_single_2: pdir 1fcb1da0 038100000eb91017 > > :1201001199222391065:ccio_map_single_1:ccio_map_single() 0x1febc096 -> > > 0x63b5096 size: 0x1000 > ... > > Exciting results? > > Yes! Nice! > > > (just what would give me DEBUG_RUN() printk() but without > > degrading system performance) > > I don't believe that. :) > Measure the CPU utilization and/or compare pktgen performance with > and without the tracing compiled into the kernel. > Having no clue about pktgen, I have a look and rebuild kernels with this option and here are some results: I use a pktgen-single script like: #!/bin/sh # "Simply" config: run single port. #modprobe pktgen function pgset() { local result echo $1 > $PGDEV result=`cat $PGDEV | fgrep "Result: OK:"` if [ "$result" = "" ]; then cat $PGDEV | fgrep Result: fi } # On UP systems only one thread exists -- so just add devices # We use eth1, eth2 echo "Adding devices to run". # eth0 interrupts on CPU0 PGDEV=/proc/net/pktgen/kpktgend_0 pgset "rem_device_all" pgset "add_device eth0" pgset "max_before_softirq 10000" # Configure the individual devices echo "Configuring devices" PGDEV=/proc/net/pktgen/eth0 pgset "clone_skb 5000000" pgset "min_pkt_size 60" pgset "max_pkt_size 60" pgset "dst 10.24.252.109" pgset "dst_mac 00:50:04:1B:2C:17" pgset "count 5000000" # Time to run PGDEV=/proc/net/pktgen/pgctrl echo "Running... ctrl^C to stop" pgset "start" # cat /proc/net/pktgen/eth? | fgrep Result === <> === And grab following results: # With Kernel including ccio_trace_marker but ccio_trace module not running Params: count 5000000 min_pkt_size: 60 max_pkt_size: 60 frags: 0 delay: 0 clone_skb: 5000000 ifname: eth0 flows: 0 flowlen: 0 queue_map_min: 0 queue_map_max: 0 dst_min: 10.24.252.109 dst_max: src_min: src_max: src_mac: 08:00:09:d2:89:15 dst_mac: 00:50:04:1b:2c:17 udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9 src_mac_count: 0 dst_mac_count: 0 Flags: Current: pkts-sofar: 455759 errors: 0 started: 1201169852886722us stopped: 1201169912731117us idle: 217617us seq_num: 455760 cur_dst_mac_offset: 0 cur_src_mac_offset: 0 cur_saddr: 0xa18fc16 cur_daddr: 0xa18fc6d cur_udp_dst: 9 cur_udp_src: 9 cur_queue_map: 0 flows: 0 Result: OK: 59844395(c59626778+d217617) usec, 455759 (60byte,0frags) 7615pps 3Mb/sec (3655200bps) errors: 0 # With Kernel including ccio_trace_marker and ccio_trace module running Params: count 5000000 min_pkt_size: 60 max_pkt_size: 60 frags: 0 delay: 0 clone_skb: 5000000 ifname: eth0 flows: 0 flowlen: 0 queue_map_min: 0 queue_map_max: 0 dst_min: 10.24.252.109 dst_max: src_min: src_max: src_mac: 08:00:09:d2:89:15 dst_mac: 00:50:04:1b:2c:17 udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9 src_mac_count: 0 dst_mac_count: 0 Flags: Current: pkts-sofar: 138863 errors: 0 started: 1201170611403245us stopped: 1201170675285642us idle: 4334664us seq_num: 138864 cur_dst_mac_offset: 0 cur_src_mac_offset: 0 cur_saddr: 0xa18fc16 cur_daddr: 0xa18fc6d cur_udp_dst: 9 cur_udp_src: 9 cur_queue_map: 0 flows: 0 Result: OK: 63882397(c59547733+d4334664) usec, 138863 (60byte,0frags) 2173pps 1Mb/sec (1043040bps) errors: 0 # With Kernel without ccio_trace_marker Params: count 5000000 min_pkt_size: 60 max_pkt_size: 60 frags: 0 delay: 0 clone_skb: 5000000 ifname: eth0 flows: 0 flowlen: 0 queue_map_min: 0 queue_map_max: 0 dst_min: 10.24.252.109 dst_max: src_min: src_max: src_mac: 08:00:09:d2:89:15 dst_mac: 00:50:04:1b:2c:17 udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9 src_mac_count: 0 dst_mac_count: 0 Flags: Current: pkts-sofar: 474350 errors: 0 started: 1201243919209991us stopped: 1201243981190756us idle: 188937us seq_num: 474351 cur_dst_mac_offset: 0 cur_src_mac_offset: 0 cur_saddr: 0xa18fc16 cur_daddr: 0xa18fc6d cur_udp_dst: 9 cur_udp_src: 9 cur_queue_map: 0 flows: 0 Result: OK: 61980765(c61791828+d188937) usec, 474350 (60byte,0frags) 7653pps 3Mb/sec (3673440bps) errors: 0 I am not sure how to read those results so I also do some ftp and grab following data: # With Kernel including ccio_trace_marker but ccio_trace module not running ftp> put linux-2.6.24-rc4-pa-git-20071206.tar.bz2 local: linux-2.6.24-rc4-pa-git-20071206.tar.bz2 remote: linux-2.6.24-rc4-pa-git-20071206.tar.bz2 200 PORT command successful. 150 Opening BINARY mode data connection for 'linux-2.6.24-rc4-pa-git-20071206.tar.bz2'. 226 Transfer complete. 47631536 bytes sent in 54.42 secs (854.8 kB/s) # With Kernel including ccio_trace_marker and ccio_trace module running ftp> put linux-2.6.24-rc4-pa-git-20071206.tar.bz2 local: linux-2.6.24-rc4-pa-git-20071206.tar.bz2 remote: linux-2.6.24-rc4-pa-git-20071206.tar.bz2 200 PORT command successful. 150 Opening BINARY mode data connection for 'linux-2.6.24-rc4-pa-git-20071206.tar.bz2'. 226 Transfer complete. 47631536 bytes sent in 59.26 secs (784.9 kB/s) # With kernel without ccio_trace_marker ftp> put linux-2.6.24-rc4-pa-git-20071206.tar.bz2 local: linux-2.6.24-rc4-pa-git-20071206.tar.bz2 remote: linux-2.6.24-rc4-pa-git-20071206.tar.bz2 200 PORT command successful. 150 Opening BINARY mode data connection for 'linux-2.6.24-rc4-pa-git-20071206.tar.bz2'. 226 Transfer complete. 47631536 bytes sent in 55.66 secs (835.8 kB/s) I agree it decrease a bit the system performance but doesn't slow it down so much that it would take several hours to boot has printk() did to me ;-) > However, that doesn't mean this is useless. This is alot better than > rolling our own "light weight" tracing mechanism and it's certainly > alot better than using printk's to debug DMA issues (as long as > the system doesn't crash - e.g. HPMC). > Yes there are limits to this method but for parisc I know so few kernel debugging tools that I would like to mentioned here the easiness of this patch implementation (even for a non C programmer as I ;<) Cheers, r. PS: I didn't put this code here just because all what I have wouldn't apply on the current p-l ccio-dma.c src. > hth, > grant > > > I still have to had some more DEBUG_RUN_SG() stuff and hope to be able to > > collect more. > > > > Cheers, > > r. > > > > --- > > Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95... > > http://www.scarlet.be/ > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-parisc" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > - > To unsubscribe from this list: send the line "unsubscribe linux-parisc" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > > --- Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95... http://www.scarlet.be/ - To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
