Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Further HEAD driver oprofile analysis
- To: linux-dvb@linuxtv.org
- Subject: [linux-dvb] Further HEAD driver oprofile analysis
- From: Dennis Noordsij <dennis.noordsij@wiral.com>
- Date: Fri, 1 Nov 2002 14:47:57 +0200
- Content-disposition: inline
- Content-transfer-encoding: quoted-printable
- Content-type: text/plain; charset="us-ascii"
- Organization: Wiral Oy
- Sender: linux-dvb-bounce@linuxtv.org
- User-agent: KMail/1.4.6
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