Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Further HEAD driver oprofile analysis



I have created a small test program which requests a TS stream from the driver 
containing one video and one audio PID. Running one instance of this program 
per card (2 altogether) consumes about 90-95% CPU, which a good test because 
it is near maxing out the CPU but without any buffers overflowing yet.

Disclaimer: RTC timing was used since the CPU does not have the counter 
necessary for cycle-accurate timings. RTC timing does not update inside an 
interrupt. (see oprofile manual for further details)

The program itself just polls the dvr filehandle, reads from the vdr device, 
and writes to a file, in a loop. 

The following 3 object files have been profiled:
DVB/driver/dvb-core.o
DVB/driver/frontends/ves1820.o
DVB/driver/av7110/dvb-ttpci.o

dvb-core.o  : 30393 samples (45.9 %)
ves1820.o  : 12 samples (irrelevant)
dvb-ttpci.o  : 35764 samples (54.1 %)

VMA     Samples    Percentage    Symbol name

dvb-ttpci.o breakdown:
0000c5c0 1493     4.17459     __constant_memcpy
000047d0 1644     4.5968      debiwrite
00005710 2038     5.69847     debiirq
00005bc0 4126     11.5367     gpioirq
00004840 6119     17.1094     debiread
00004750 20152    56.3472     wait_for_debi_done

wait_for_debi_done breakdown:
00004766 9596     47.6181           driver/av7110/av7110.c:206
0000479a 6073     30.136             driver/av7110/av7110.c:218

Both of these lines call saaread(), i.e:

    203     /* wait for registers to be programmed */
    204     start = jiffies;
    205     while (1) {
    206                 if (saaread(MC2) & 2)
    207                         break;
    208         if (jiffies-start > HZ/20) {
    209             printk ("%s: timed out while waiting for registers "
    210                 "getting programmed\n", __FUNCTION__);
    211             return -ETIMEDOUT;
    212         }
    213     }
    214
    215     /* wait for transfer to complete */
    216     start = jiffies;
    217     while (1) {
    218         if (!(saaread(PSR) & SPCI_DEBI_S))
    219             break;
    220         saaread(MC2);
    221         if (jiffies-start > HZ/4) {
    222             printk ("%s: timed out while waiting for transfer "
    223                 "completion\n", __FUNCTION__);
    224             return -ETIMEDOUT;
    225         }
    226     }

saaread, after some #define's, goes back to a readl() call. A large part of 
the CPU consumption of this object file goes to saaread and write calls.

To me that doesn't mean much :-) But maybe someone can say wether this looks 
OK or not?


Then, dvb-core.o:
00000890 1        0.00329023  DmxDevFilterStop
000010c0 1        0.00329023  dvb_demux_do_ioctl
000073f0 1        0.00329023  dvb_frontend_get_event
00008970 1        0.00329023  __constant_memcpy
00008f40 1        0.00329023  dvb_generic_ioctl
000076f0 7        0.0230316   update_delay
00007030 13       0.042773    dvb_frontend_internal_ioctl
00007840 15       0.0493535   dvb_frontend_is_exiting
00007890 22       0.0723851   dvb_frontend_thread
000004e0 1174     3.86273     dvb_dvr_read
00001c10 1410     4.63923     DvbDmxSWFilterPackets
00001350 3106     10.2195     dvb_dvr_poll
00000710 3179     10.4596     DmxDevTSCallback
00000000 3793     12.4798     DmxDevBufferRead
00001ae0 3799     12.4996     DvbDmxSWFilterPacket
00001740 13870    45.6355     DmxDevBufferWrite

A significant part of this is spent in memcpy calls, for which I guess the 
lack of any mmx etc registers on this particular CPU is to blame. (otherwise 
kernel memcpy would use it?). Other than reducing the number of copies going 
around, this is the way it is :-)


Any comments, or further information requested?

Cheers,
Dennis



--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index