PROMBLEM: CD burning at 16x uses excessive CPU, although DMA is enabled
[1.] One line summary of the problem:
CD burning at 16x uses excessive CPU, although DMA is enabled
[2.] Full description of the problem/report:
My system seems to use a lot of CPU time when writing CDs at 16x. The system is unable to feed the burning software's buffer fast enough when burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user. If run as root, system is almost unresponsive during the burn.
This concerns only audio and raw data burns, burning of ISO images goes fine with very little load. 12x and 8x burns are also fine, although using serial ports is error prone while even a 8x burn is going on. CD Writer is LG GCE-8160B, secondary master, alone in the cable. CD writer and HD has DMA enabled, by default writer uses mdma2. Other modes have been tried, but no change. Disabling DMA does not help.
This problem does not happen in FreeBSD 4.5-STABLE with cdrecord 1.11a20.
[3.] Keywords (i.e., modules, networking, kernel):
CD writing, ATAPI, SG
[4.] Kernel version (from /proc/version):
2.4.18, 2.4.16, 2.2.19, 2.4.19pre6
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here) Linux dorkstar 2.4.18 #2 Wed Apr 3 22:03:26 EEST 2002 i686 unknown
Gnu C 2.95.4 Gnu make 3.79.1 util-linux 2.11n mount 2.11n modutils 2.4.13 e2fsprogs 1.26 Linux C Library 2.2.5 Dynamic linker (ldd) 2.2.5 Procps 2.0.7 Net-tools 1.60 Kbd command Sh-utils 2.0.11 Modules Loaded sg cmpci soundcore ncr53c8xx isofs via686a i2c-proc i2c-isa i2c-core autofs4 lirc_serial ip_conntrack_ftp ipt_REJECT ipt_limit ipt_LOG ipt_state ip_conntrack iptable_filter ip_tables 3c59x ide-scsi sr_mod cdrom rtc nls_iso8859-1 nls_cp437 vfat fat
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0vendor_id : AuthenticAMD
cpu family : 6
model : 3
model name : AMD Duron(tm) processor
stepping : 1
cpu MHz : 799.649
cache size : 64 KBfdiv_bug : nohlt_bug : nof00f_bug : nocoma_bug : no
fpu : yesfpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 1595.80
[7.3.] Module information (from /proc/modules):
sg 25124 0 (autoclean) cmpci 25380 0 (autoclean) soundcore 3652 2 (autoclean) [cmpci] ncr53c8xx 53184 0 isofs 18016 0 (autoclean) via686a 8036 0 (unused) i2c-proc 6144 0 [via686a] i2c-isa 1188 0 (unused) i2c-core 13128 0 [via686a i2c-proc i2c-isa] autofs4 8644 2 (autoclean) lirc_serial 7520 0 ip_conntrack_ftp 3424 0 (unused) ipt_REJECT 2976 1 (autoclean) ipt_limit 928 3 (autoclean) ipt_LOG 3200 13 (autoclean) ipt_state 576 2 (autoclean) ip_conntrack 13548 2 (autoclean) [ip_conntrack_ftp ipt_state] iptable_filter 1760 1 (autoclean) ip_tables 10944 5 [ipt_REJECT ipt_limit ipt_LOG ipt_state iptable_filter] 3c59x 25608 1 (autoclean) ide-scsi 7712 0 (autoclean) sr_mod 13624 0 (autoclean) cdrom 28512 0 (autoclean) [sr_mod] rtc 5656 0 (autoclean) nls_iso8859-1 2848 2 (autoclean) nls_cp437 4384 2 (autoclean) vfat 9916 2 (autoclean) fat 31576 0 (autoclean) [vfat]
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) /proc/ioports :
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : lirc_serial
0cf8-0cff : PCI conf1
5000-500f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] 6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
6000-607f : via686a-sensors
c000-c00f : VIA Technologies, Inc. Bus Master IDE
c000-c007 : ide0
c008-c00f : ide1
c400-c41f : VIA Technologies, Inc. UHCI USB
c800-c81f : VIA Technologies, Inc. UHCI USB (#2)
cc00-ccff : ATI Technologies Inc 3D Rage Pro 215GP
d000-d07f : 3Com Corporation 3c905C-TX [Fast Etherlink]
d000-d07f : 00:09.0
d400-d4ff : LSI Logic / Symbios Logic (formerly NCR) 53c810
d400-d47f : ncr53c8xx
d800-d8ff : C-Media Electronics Inc CM8738
d800-d8ff : cmpci
dc00-dc07 : Promise Technology, Inc. 20265
dc00-dc07 : ide2
e000-e003 : Promise Technology, Inc. 20265
e002-e002 : ide2
e400-e407 : Promise Technology, Inc. 20265
e800-e803 : Promise Technology, Inc. 20265
ec00-ec3f : Promise Technology, Inc. 20265
ec00-ec07 : ide2
ec08-ec0f : ide3
ec10-ec3f : PDC20265
/proc/iomem:
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-0ffeffff : System RAM
00100000-001fe615 : Kernel code
001fe616-0024a0b7 : Kernel data
0fff0000-0fff2fff : ACPI Non-volatile Storage 0fff3000-0fffffff : ACPI Tables
d0000000-d7ffffff : PCI Bus #01
d0000000-d7ffffff : nVidia Corporation NV11 (GeForce2 MX)
d8000000-dbffffff : VIA Technologies, Inc. VT8363/8365 [KT133/KM133] dc000000-ddffffff : PCI Bus #01
dc000000-dcffffff : nVidia Corporation NV11 (GeForce2 MX)
de000000-deffffff : ATI Technologies Inc 3D Rage Pro 215GP e0000000-e001ffff : Promise Technology, Inc. 20265 e0020000-e002007f : 3Com Corporation 3c905C-TX [Fast Etherlink] e0021000-e00210ff : LSI Logic / Symbios Logic (formerly NCR) 53c810 e0022000-e0022fff : ATI Technologies Inc 3D Rage Pro 215GP ffff0000-ffffffff : reserved
[7.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
Latency: 0
Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: dc000000-ddffffff
Prefetchable memory behind bridge: d0000000-d7ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Region 4: I/O ports at c000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 5
Region 4: I/O ports at c400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 5
Region 4: I/O ports at c800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 9
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:08.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 0000
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Region 0: Memory at de000000 (32-bit, prefetchable) [disabled] [size=16M] Region 1: I/O ports at cc00 [disabled] [size=256]
Region 2: Memory at e0022000 (32-bit, non-prefetchable) [disabled] [size=4K] Expansion ROM at <unassigned> [disabled] [size=128K]
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management NIC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2500ns min, 2500ns max), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at d000 [size=128]
Region 1: Memory at e0020000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00:0a.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR) 53c810 (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at d400 [size=256]
Region 1: Memory at e0021000 (32-bit, non-prefetchable) [size=256]
00:0d.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
Subsystem: C-Media Electronics Inc CMI8738/C3DX PCI Audio Device
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (500ns min, 6000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at d800 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0f.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02)
Subsystem: Promise Technology, Inc.: Unknown device 4d33
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at dc00 [size=8]
Region 1: I/O ports at e000 [size=4]
Region 2: I/O ports at e400 [size=8]
Region 3: I/O ports at e800 [size=4]
Region 4: I/O ports at ec00 [size=64]
Region 5: Memory at e0000000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [58] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: nVidia Corporation NV11 (GeForce2 MX) (rev a1) (prog-if 00 [VGA])
Subsystem: Elsa AG: Unknown device 0c60
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
[7.6.] SCSI information (from /proc/scsi/scsi) Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: HL-DT-ST Model: CD-RW GCE-8160B Rev: 2.01
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: NEC Model: CD-ROM DRIVE:462 Rev: 1.16
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 02 Lun: 00
Vendor: RICOH Model: CD-R/RW MP7060S Rev: 1.70
Type: CD-ROM ANSI SCSI revision: 02
Quoted 2 lines · Anssi Saari
[1.] One line summary of the problem:
CD burning at 16x uses excessive CPU, although DMA is enabled
That's a hint things are not working as you expect...
Quoted 5 lines
[2.] Full description of the problem/report:
My system seems to use a lot of CPU time when writing CDs at 16x. The system is unable to feed the burning software's buffer fast enough when burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user. If run as root, system is almost unresponsive during the burn.
With all the information you provided, you have totally not quatified
how much CPU you find "excessive." I would not be surprised to see 10-15% of the CPU, virtually all in system time, as a normal burn of an ISO image. If the time is in user mode with other image types, it may well be that you are doing something which actually requires a lot of CPU (byte swapping or some such).
Going from a disk to a CD using DMA on both should not take much
*system* CPU, even if these are ATAPI (assuming they are not on the same cable).
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
I'm not completely sure about burning audio, but linux doesn't read audio cds using DMA. It just wont on ide devices. You can use a patch that allows this from andrew morton. I dont write many audio cds so I've never tested it's effect on writing a cd, only reading. I imagine it's not safe to use dma on raw/audio cds. but go check it out anyways.
Quoted 34 lines · Bill Davidsen
Quoted 2 lines · Anssi Saari
[1.] One line summary of the problem:
CD burning at 16x uses excessive CPU, although DMA is enabledThat's a hint things are not working as you expect...
Quoted 5 lines
[2.] Full description of the problem/report:
My system seems to use a lot of CPU time when writing CDs at 16x. The system is unable to feed the burning software's buffer fast enough when burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user. If run as root, system is almost unresponsive during the burn.With all the information you provided, you have totally not quatified
how much CPU you find "excessive." I would not be surprised to see 10-15% of the CPU, virtually all in system time, as a normal burn of an ISO image. If the time is in user mode with other image types, it may well be that you are doing something which actually requires a lot of CPU (byte swapping or some such).Going from a disk to a CD using DMA on both should not take much
*system* CPU, even if these are ATAPI (assuming they are not on the same cable).Signature · 9 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · Ed Sweetman
I'm not completely sure about burning audio, but linux doesn't read audio cds using DMA. It just wont on ide devices. You can use a patch that allows this from andrew morton. I dont write many audio cds so I've never tested it's effect on writing a cd, only reading. I imagine it's not safe to use dma on raw/audio cds. but go check it out anyways.
I've seen the patch, but the OP was posting about burning CDs. My
recollection is that even audio CDs don't use much CPU with DMA, but there might be lots of options and stuff involved. I've asked for a breakdown of CPU use so we can see if it's user or system, how much, etc.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 2 lines · Ed Sweetman
I'm not completely sure about burning audio, but linux doesn't read audio cds using DMA.
I didn't think this is relevant, except if I were trying to copy a CD on the fly, but that's not the case. But I have now tried it, no change. In fact, what I tried was this linux-2.4.19-pre5-jam2 patch collection which includes that and low latency and O(1) scheduler patches, among other things. Didn't seem to help, however.
Quoted 7 lines · Bill Davidsen
Quoted 2 lines · Anssi Saari
[1.] One line summary of the problem:
CD burning at 16x uses excessive CPU, although DMA is enabledThat's a hint things are not working as you expect...
Quoted 8 lines
Quoted 5 lines
[2.] Full description of the problem/report:
My system seems to use a lot of CPU time when writing CDs at 16x. The system is unable to feed the burning software's buffer fast enough when burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user. If run as root, system is almost unresponsive during the burn.With all the information you provided, you have totally not quatified
how much CPU you find "excessive."
I didn't really know how to put it. Maybe system load would be better. But the actual problem is, I effectively can't burn audio and other types at 16x in Linux, while there is no problem in some other operating systems with the same hardware and applications.
Here're some time figures from cdrdao:
cdrdao simulate -n --speed 8 foo.cue 2.62s user 3.37s system 1% cpu 6:41.86 total cdrdao simulate -n --speed 12 foo.cue 2.78s user 29.91s system 12% cpu 4:31.71 total cdrdao simulate -n --speed 16 foo.cue 2.67s user 128.77s system 52% cpu 4:10.68 total
So yes, system time goes up quite steeply.
But even though 50% is quite high, CPU load is not the problem as such, the problem is getting data to the writer fast enough. And it's not happening. Even a single audio track that is completely cached so that there is no HD access has problems. It's like somehow accessing the CD writer hogs the system for such long periods that there is insufficient time to fill the writing program's buffer.
One thing I noticed just now. If I turn off unmaskirq for the CD writer with hdparm -u 0 /dev/hdc, it helps a little, but not enough. Time reports now:
cdrdao simulate -n --speed 16 foo.cue 2.75s user 75.18s system 58% cpu 2:13.22 total
Quoted 22 lines · Anssi Saari
Quoted 7 lines · Bill Davidsen
Quoted 2 lines · Anssi Saari
[1.] One line summary of the problem:
CD burning at 16x uses excessive CPU, although DMA is enabledThat's a hint things are not working as you expect...
Quoted 8 lines
Quoted 5 lines
[2.] Full description of the problem/report:
My system seems to use a lot of CPU time when writing CDs at 16x. The system is unable to feed the burning software's buffer fast enough when burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user. If run as root, system is almost unresponsive during the burn.With all the information you provided, you have totally not quatified
how much CPU you find "excessive."I didn't really know how to put it. Maybe system load would be better. But the actual problem is, I effectively can't burn audio and other types at 16x in Linux, while there is no problem in some other operating systems with the same hardware and applications.
Quoted 7 lines
Here're some time figures from cdrdao:
cdrdao simulate -n --speed 8 foo.cue 2.62s user 3.37s system 1% cpu 6:41.86 total cdrdao simulate -n --speed 12 foo.cue 2.78s user 29.91s system 12% cpu 4:31.71 total cdrdao simulate -n --speed 16 foo.cue 2.67s user 128.77s system 52% cpu 4:10.68 total
So yes, system time goes up quite steeply.
Okay, this is good information. At the risk of asking a dumb question,
are you sure that both the burner and the source drive ar using DMA? And that they are on separate cables (controllers)? Usually the high system time indicated either PIO in use or some path looping in the kernel.
Quoted 2 lines
cdrdao simulate -n --speed 16 foo.cue 2.75s user 75.18s system 58% cpu 2:13.22 total
That's still high. My only fast burners are in the office, if I get back
during the week I'll run a test at 16 and 24x and see what I find.
This would be a good question for the CD writing list,
[email protected].
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 2 lines · Bill Davidsen
Okay, this is good information. At the risk of asking a dumb question,
are you sure that both the burner and the source drive ar using DMA?
I'm fairly certain. I can read that test image at ~37MB/s and 35% CPU, which can't be PIO. The CD writer reads at ~3.7MB/s and 3% CPU usage.
Quoted 1 line
that they are on separate cables (controllers)?
Yes. Two HDs, one writer, all on different channels. The other HD is on the motherboards Promise 20265 "raid" controller.
Quoted 2 lines
This would be a good question for the CD writing list,
[email protected].
I tried that some time ago. So far, this is a sort of repetition of that. Joerg Schilling suggested that maybe I don't have DMA on or the reader and writer are on the same cable. Other discussion was off topic...
In fact, I've also had this conversation from the other point of view with someone else, who was asking about this same problem in the finnish Linux group, sfnet.atk.linux. Now I have the same LG CD writer, the same VIA KT133A chipset, the same problem and the same discussion... I'd be amused if the problem weren't still unresolved.
I decided to post here after I tried FreeBSD, didn't have a problem and thus it seemed likely that this is a Linux specific problem.
I think I'll try to put together another system and see what happens there. I wonder if SGI's kernprof thing would be useful with this. I'll try that too, when I have the time.
Hi,
I tested with my computer - the CD-R:s that I had limited the testing to 10x. But when testing that it indicated 33% CPU in system, but not accouted to any process by top.
I have done some profiling with my kernel 2.4.17-rmap12f
I think this indicates that the time spent for this kernel is IRQ happening during idle time - correct?
I am not sure that this is the same situation that Anssi has but 33% are quite a lot (more than he got, DMAs are enabled). But at least it is another comparative datapoint...
/RogerL
--- output from readprofile (>=3) ------------------
3 __aux_write_ack 0.0938
3 kmalloc 0.0115
3 pipe_poll 0.0300
3 sys_select 0.0026
4 add_wait_queue 0.1000
4 link_path_walk 0.0021
4 rest_init 0.1000
4 rmqueue 0.0059
4 tasklet_action 0.0303
4 timer_bh 0.0066
5 __free_pages_ok 0.0068
5 sock_poll 0.1250
6 __rdtsc_delay 0.2143
6 __switch_to 0.0326
6 __wake_up 0.0375
6 kfree 0.0405
7 fget 0.1750
7 poll_freewait 0.1029
7 sys_write 0.0357
8 unix_poll 0.0541
9 schedule 0.0110
11 do_softirq 0.0671
12 do_anonymous_page 0.0517
12 do_select 0.0252
23 handle_IRQ_event 0.2614
24 file_read_actor 0.1765 5960 ide_intr 17.7381
36056 default_idle 901.4000
42283 total 0.0418
Quoted 36 lines · Anssi Saari
Quoted 2 lines · Bill Davidsen
Okay, this is good information. At the risk of asking a dumb question,
are you sure that both the burner and the source drive ar using DMA?I'm fairly certain. I can read that test image at ~37MB/s and 35% CPU, which can't be PIO. The CD writer reads at ~3.7MB/s and 3% CPU usage.
Quoted 1 line
that they are on separate cables (controllers)?
Yes. Two HDs, one writer, all on different channels. The other HD is on the motherboards Promise 20265 "raid" controller.
Quoted 2 lines
This would be a good question for the CD writing list,
[email protected].I tried that some time ago. So far, this is a sort of repetition of that. Joerg Schilling suggested that maybe I don't have DMA on or the reader and writer are on the same cable. Other discussion was off topic...
In fact, I've also had this conversation from the other point of view with someone else, who was asking about this same problem in the finnish Linux group, sfnet.atk.linux. Now I have the same LG CD writer, the same VIA KT133A chipset, the same problem and the same discussion... I'd be amused if the problem weren't still unresolved.
I decided to post here after I tried FreeBSD, didn't have a problem and thus it seemed likely that this is a Linux specific problem.
I think I'll try to put together another system and see what happens there. I wonder if SGI's kernprof thing would be useful with this. I'll try that too, when I have the time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 3 lines
Roger Larsson Skellefteå Sweden
Quoted 3 lines · Mark Hahn
I think someone else already pointed out that doing a kernel profile would be good. strace would also be quite useful, even just the -c form.
Here it is:
With unmaskirq=1 first:
3 block_read_full_page 0.0059
3 fget 0.0625
3 get_unused_buffer_head 0.0234
3 kmalloc 0.0134
3 kmem_cache_free 0.0187
4 __free_pages_ok 0.0081
4 ext3_get_branch 0.0147
4 get_hash_table 0.0278
4 journal_try_to_free_buffers 0.0278
4 rmqueue 0.0093
4 scsi_old_done 0.0027
5 generic_make_request 0.0164
5 try_to_free_buffers 0.0223
6 ext3_releasepage 0.1250
6 sys_read 0.0268
6 system_call 0.1071
7 __rdtsc_delay 0.2188
7 apm_bios_call 0.0547
7 scsi_request_fn 0.0093
8 __make_request 0.0050
8 ide_wait_stat 0.0294
8 schedule 0.0091
9 ide_dmaproc 0.0161
9 start_request 0.0148
13 do_generic_file_read 0.0123
14 ide_end_request 0.0972
22 do_rw_disk 0.0229
49 handle_IRQ_event 0.5104
239 file_read_actor 2.4896 3324 default_idle 69.2500
20097 ide_output_data 104.6719
23952 total 0.0236
Number of interrupts on ide1 during burn: 17531
And then, unmaskirq=0:
3 __free_pages 0.0938
3 ext3_get_branch 0.0110
3 fget 0.0625
3 kmem_cache_reap 0.0069
3 page_cache_read 0.0156
3 scsi_block_when_processing_errors 0.0144
3 shrink_cache 0.0042
4 __make_request 0.0025
4 __rdtsc_delay 0.1250
4 __switch_to 0.0208
4 ext3_get_block_handle 0.0058
4 fput 0.0179
4 get_unused_buffer_head 0.0312
4 ide_dma_intr 0.0208
4 ide_dmaproc 0.0071
4 ide_output_data 0.0208
4 kfree 0.0250
4 kmem_cache_free 0.0250
4 rmqueue 0.0093
4 sys_read 0.0179
4 try_to_free_buffers 0.0179
6 ext3_releasepage 0.1250
6 generic_file_readahead 0.0179
6 timer_bh 0.0099
7 scsi_old_done 0.0048
8 start_request 0.0132
8 system_call 0.1429
9 ide_wait_stat 0.0331
10 do_generic_file_read 0.0095
10 ide_end_request 0.0694
10 schedule 0.0114
11 do_rw_disk 0.0115
15 apm_bios_call 0.1172
168 do_softirq 0.9545
234 file_read_actor 2.4375
1942 handle_IRQ_event 20.2292
2949 default_idle 61.4375
6808 ide_intr 18.5000 12333 total 0.0122
Number of interrupts on ide1 during burn: 17532
Strace -c with unmaskirq=1:
execve("/usr/local/bin/cdrdao", ["cdrdao", "simulate", "-n", "--speed", "16", "f oo.cue"], [/* 34 vars */]) = 0
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
95.66 2.141856 244 8767 ioctl 2.16 0.048346 3 17516 gettimeofday 1.08 0.024089 45 534 write 0.51 0.011371 2 5826 rt_sigprocmask 0.43 0.009593 564 17 5 open 0.10 0.002251 225 10 1 read 0.03 0.000694 174 4 munmap 0.01 0.000314 1 314 nanosleep 0.01 0.000122 7 18 old_mmap 0.00 0.000055 5 12 close 0.00 0.000053 5 10 brk 0.00 0.000041 21 2 2 rt_sigsuspend 0.00 0.000033 2 16 rt_sigaction 0.00 0.000029 29 1 pipe 0.00 0.000028 3 11 fstat64 0.00 0.000024 5 5 mprotect 0.00 0.000021 21 1 clone 0.00 0.000010 10 1 wait4 0.00 0.000010 5 2 2 sigreturn 0.00 0.000008 4 2 uname 0.00 0.000008 8 1 _sysctl 0.00 0.000008 3 3 fcntl64 0.00 0.000003 3 1 1 munlockall 0.00 0.000003 2 2 geteuid32 0.00 0.000002 2 1 getpid 0.00 0.000002 2 1 setrlimit 0.00 0.000002 2 1 getrlimit
------ ----------- ----------- --------- --------- ----------------
100.00 2.238976 33079 11 total
and with unmaskirq=0:
execve("/usr/local/bin/cdrdao", ["cdrdao", "simulate", "-n", "--speed", "16", "f oo.cue"], [/* 34 vars */]) = 0
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.75 35.801229 4084 8767 ioctl 0.14 0.051375 3 17516 gettimeofday 0.07 0.024269 45 534 write 0.03 0.011883 2 5826 rt_sigprocmask 0.00 0.000709 177 4 munmap 0.00 0.000267 18 15 3 open 0.00 0.000263 1 263 nanosleep 0.00 0.000117 7 18 old_mmap 0.00 0.000083 8 10 1 read 0.00 0.000057 29 2 2 rt_sigsuspend 0.00 0.000056 5 12 close 0.00 0.000048 5 10 brk 0.00 0.000036 2 16 rt_sigaction 0.00 0.000029 29 1 pipe 0.00 0.000028 3 11 fstat64 0.00 0.000026 5 5 mprotect 0.00 0.000020 20 1 clone 0.00 0.000010 5 2 2 sigreturn 0.00 0.000009 9 1 wait4 0.00 0.000008 4 2 uname 0.00 0.000008 8 1 _sysctl 0.00 0.000007 2 3 fcntl64 0.00 0.000003 3 1 setrlimit 0.00 0.000003 3 1 1 munlockall 0.00 0.000003 3 1 getrlimit 0.00 0.000003 2 2 geteuid32 0.00 0.000002 2 1 getpid
------ ----------- ----------- --------- --------- ----------------
100.00 35.890551 33026 9 total
Quoted 3 lines
Quoted 1 line
But even though 50% is quite high, CPU load is not the problem as such,
50% of what CPU?
AMD Duron 800MHz. Of course it's a problem but not the main problem here.
Quoted 1 line
it would also be interesting to look at memory behavior.
How would I get that?
I think the fact that it works with FreeBSD should have been enough to show that 'excessive' doesn't need to be qualified.
The question is, how is CD burning of raw data different from CD burning of ISO images, in respect to Linux drivers for the hardware, and why does FreeBSD not suffer from this ailment?
mark
Quoted 23 lines · Bill Davidsen
Quoted 2 lines · Anssi Saari
[1.] One line summary of the problem:
CD burning at 16x uses excessive CPU, although DMA is enabledThat's a hint things are not working as you expect...
Quoted 5 lines
[2.] Full description of the problem/report:
My system seems to use a lot of CPU time when writing CDs at 16x. The system is unable to feed the burning software's buffer fast enough when burning software (cdrecord 1.11a20, cdrdao 1.1.5) is run as normal user. If run as root, system is almost unresponsive during the burn.With all the information you provided, you have totally not quatified
how much CPU you find "excessive." I would not be surprised to see 10-15% of the CPU, virtually all in system time, as a normal burn of an ISO image. If the time is in user mode with other image types, it may well be that you are doing something which actually requires a lot of CPU (byte swapping or some such).Going from a disk to a CD using DMA on both should not take much
*system* CPU, even if these are ATAPI (assuming they are not on the same cable).
Signature · 9 lines
[email protected]/[email protected]/[email protected] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/
Quoted 6 lines · Mark Mielke
I think the fact that it works with FreeBSD should have been enough to show that 'excessive' doesn't need to be qualified.
The question is, how is CD burning of raw data different from CD burning of ISO images, in respect to Linux drivers for the hardware, and why does FreeBSD not suffer from this ailment?
Let's say it didn't give me a clue how much time was being used and
where. There are various options like bytes swap which could drive up user time, and other things like PIO which drive up system.
I find I give a better quality of help if I understand the problem...
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
Quoted 3 lines · Mark Mielke
The question is, how is CD burning of raw data different from CD burning of ISO images, in respect to Linux drivers for the hardware
As far as I know, when burning an ISO image, the image has 2048 byte sectors to which the CD writer adds error correction data so that the individual sector becomes 2352 bytes. A raw data image includes 2352 byte sectors. The obvious difference would be a higher data rate (2352/2048 or 1.15x more) from computer to writer.
Quoted 13 lines · Anssi Saari
Date: Tue, 9 Apr 2002 11:32:43 +0300
From: Anssi Saari <[email protected]>
To: Mark Mielke <[email protected]>
Cc: [email protected]
Subject: Re: PROMBLEM: CD burning at 16x uses excessive CPU,
although DMA is enabledQuoted 3 lines · Mark Mielke
The question is, how is CD burning of raw data different from CD burning of ISO images, in respect to Linux drivers for the hardware
Quoted 6 lines
As far as I know, when burning an ISO image, the image has 2048 byte sectors to which the CD writer adds error correction data so that the individual sector becomes 2352 bytes. A raw data image includes 2352 byte sectors. The obvious difference would be a higher data rate (2352/2048 or 1.15x more) from computer to writer.
I have seen something similar when reading CD-Rs (with ISO image burnt); After I burn a CD I run readcd -c2scan to see if I get any C2 errors; I am using ASUS 50x CD drive, usually setting the speed to 45x before the operation (my TEAC CD-RW drive always run at 4x when doing readcd -c2scan, which is too slow for my patience).
The interesting thing is that while reading ISO image with dd the system works fine, readcd -c2scan makes it often very unresponsible (just switching between virtual desktops in KDE may take up to several seconds).
The system is Pentium III running at 720 MHz, ABIT RAID-133 motherboard, hard disk connected to HPT-370A, CD and CD-RW drived on separate channels, kernel 2.2.19 + IDE patches, 768 MB RAM.
I am wondering if you could possibly compare the system behaviour with Linux and FreeBSD when using readcd -c2scan (assuming readcd -c2scan works with your drives at some reasonable speeds).
Best regards,
Wojtek
Quoted 12 lines · Anssi Saari
I didn't really know how to put it. Maybe system load would be better. But the actual problem is, I effectively can't burn audio and other types at 16x in Linux, while there is no problem in some other operating systems with the same hardware and applications.
Here're some time figures from cdrdao:
cdrdao simulate -n --speed 8 foo.cue 2.62s user 3.37s system 1% cpu 6:41.86 total cdrdao simulate -n --speed 12 foo.cue 2.78s user 29.91s system 12% cpu 4:31.71 total cdrdao simulate -n --speed 16 foo.cue 2.67s user 128.77s system 52% cpu 4:10.68 total
Quoted 8 lines
So yes, system time goes up quite steeply.
But even though 50% is quite high, CPU load is not the problem as such, the problem is getting data to the writer fast enough. And it's not happening. Even a single audio track that is completely cached so that there is no HD access has problems. It's like somehow accessing the CD writer hogs the system for such long periods that there is insufficient time to fill the writing program's buffer.
You may try profiling kernel to see where it exactly spending that time. It has an added benefit: you will learn how to profile kernels (if you don't know how to do it already).
I am waiting for similar problem to bite me to learn that, too. :-)
Quoted 6 lines
One thing I noticed just now. If I turn off unmaskirq for the CD writer with hdparm -u 0
/dev/hdc, it helps a little, but not enough. Time reports now:cdrdao simulate -n --speed 16 foo.cue 2.75s user 75.18s system 58% cpu 2:13.22 total
--
vda
Quoted 10 lines · Anssi Saari
Quoted 3 lines · Mark Mielke
The question is, how is CD burning of raw data different from CD burning of ISO images, in respect to Linux drivers for the hardware
As far as I know, when burning an ISO image, the image has 2048 byte sectors to which the CD writer adds error correction data so that the individual sector becomes 2352 bytes. A raw data image includes 2352 byte sectors. The obvious difference would be a higher data rate (2352/2048 or 1.15x more) from computer to writer.
It means different write command, additional (possibly less carefully written/tested) driver code etc. You may need to track your problem up to that driver code.
--
vda