ide-cs using 100% CPU
I have a thinkpad r50p, 1.6GHz CPU, 512MB memory running kernel 2.6.7-mm4 (Also tried 2.6.7, 2.6.6, 2.6.4 and a few others).
When reading from CF card (using ide-cs) the system is really stodgy and consumes 100% CPU. Almost all of it waitIO according to top...
Now it's not the fact that I get lots of waitIO, but AFAIUI if a system uses truckloads of waitIO, that should just mean that the system is idle but there's some IO going on & a process is waiting for it to complete (e.g. the way AIX does it).
Other processes should still be able to get CPU without any problems, but my experience is that under Linux if waitio is due to reading the CF card, the system essentially stops... The mouse still moves (Under X), but... unwillingly... Jerking around all over the place...
Anyone know why this happens? Something busy waiting? (BUt that should show as system cpu right?) or something taking out really long locks?
Quoted 2 lines · Hamie
Anyone know why this happens? Something busy waiting? (BUt that should show as system cpu right?) or something taking out really long locks?
It'll be because IDE is using PIO to access the CF card, which could have long access times (so reading a block of sectors could take some time _and_ use CPU.) Obviously, PIO requires the use of the CPU, so the CPU can't be handed off to some other task while this is occuring.
Signature · 4 lines
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial coreQuoted 14 lines · Russell King
Quoted 3 lines · Hamie
Anyone know why this happens? Something busy waiting? (BUt that should show as system cpu right?) or something taking out really long locks?
It'll be because IDE is using PIO to access the CF card, which could have long access times (so reading a block of sectors could take some time _and_ use CPU.) Obviously, PIO requires the use of the CPU, so the CPU can't be handed off to some other task while this is occuring.
Well... I did consider that. And not to disbelieve you, since you know the kernel way better than I do, But decided I was being silly that a 1.6GHz Pentium-M processor should use 100% CPU moving a couple of MB/second across a CF interface...
Is 100% CPU not excessive? IIRC my PIII-750 used to use less CPU doing the same job as quick, or even slightly faster...
And should it not use system CPU rather than user CPU?
TIA
Hamish.
Quoted 22 lines · Hamie
Quoted 8 lines · Russell King
Quoted 4 lines · Hamie
Anyone know why this happens? Something busy waiting? (BUt that should show as system cpu right?) or something taking out really long locks?
Quoted 7 lines
It'll be because IDE is using PIO to access the CF card, which could have long access times (so reading a block of sectors could take some time _and_ use CPU.) Obviously, PIO requires the use of the CPU, so the CPU can't be handed off to some other task while this is occuring.
Well... I did consider that. And not to disbelieve you, since you know the kernel way better than I do, But decided I was being silly that a 1.6GHz Pentium-M processor should use 100% CPU moving a couple of MB/second across a CF interface...
Quoted 4 lines
Is 100% CPU not excessive? IIRC my PIII-750 used to use less CPU doing the same job as quick, or even slightly faster...
And should it not use system CPU rather than user CPU?
Actually, if its being accounted for as waitIO, then we should be running some other task... However, I've just realised that we don't appear to specifically account IO waits in the kernel, so I'm not sure how userspace comes up with this magic number.
Sorry for the noise...
Signature · 4 lines
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial coreQuoted 34 lines · Russell King
Quoted 23 lines · Hamie
Quoted 10 lines · Russell King
Quoted 5 lines · Hamie
Anyone know why this happens? Something busy waiting? (BUt that should show as system cpu right?) or something taking out really long locks?
Quoted 9 lines
It'll be because IDE is using PIO to access the CF card, which could have long access times (so reading a block of sectors could take some time _and_ use CPU.) Obviously, PIO requires the use of the CPU, so the CPU can't be handed off to some other task while this is occuring.
Quoted 7 lines
Well... I did consider that. And not to disbelieve you, since you know the kernel way better than I do, But decided I was being silly that a 1.6GHz Pentium-M processor should use 100% CPU moving a couple of MB/second across a CF interface...
Is 100% CPU not excessive? IIRC my PIII-750 used to use less CPU doing the same job as quick, or even slightly faster...
And should it not use system CPU rather than user CPU?
Quoted 9 lines
Actually, if its being accounted for as waitIO, then we should be running some other task... However, I've just realised that we don't appear to specifically account IO waits in the kernel, so I'm not sure how userspace comes up with this magic number.
Sorry for the noise...
Hey... Make all the noise you like. If I knew the internals a bit more nowadays, I'd find it determine why it looks like userCPU myself.
Why doesn't the kernel account for waitIO? Design decision? or just not yet implemented? Or not wanted (Not sure why it'd be the third or first :). Bug?
H
Quoted 2 lines · Hamie
Is 100% CPU not excessive? IIRC my PIII-750 used to use less CPU doing the same job as quick, or even slightly faster...
PCMCIA IDE is PIO only so it burns CPU. This is one case where hyperthreading is nice. Cardbus IDE is a lot better but very little exists and we don't currently support hotplug IDE controllers.
Quoted 1 line
And should it not use system CPU rather than user CPU?
Yes - but figure out please if the kernel or userspace is getting that wrong ;)
Alan
Quoted 13 lines · Alan Cox
Quoted 3 lines · Hamie
Is 100% CPU not excessive? IIRC my PIII-750 used to use less CPU doing the same job as quick, or even slightly faster...
PCMCIA IDE is PIO only so it burns CPU. This is one case where hyperthreading is nice. Cardbus IDE is a lot better but very little exists and we don't currently support hotplug IDE controllers.
Ah right. But would a CF memory card be cardbus anyway?
Quoted 9 lines
Quoted 3 lines
And should it not use system CPU rather than user CPU?
Yes - but figure out please if the kernel or userspace is getting that wrong ;)
My apologies. It was gkrellm leading me up the garden path on that one... Copying about 100MB from a 512MB CF card (25+ photos from my camera) vmstat 5 reports 4% usercpu, 96% system cpu. And the response on the system is sluggish to say the least. (Moving the pointer in X is painful :). gkrell meanwhile on it's cpu graph shows about 30% system, and the rest as userCPU. No idea why, I guess till I find out I'll just regard gkrellm's cpu graph as a waste of space (To differentiate system & user cpu anyway :).
Quoted 2 lines
hdparm -u1 /dev/hd[whatever]
will help a lot on the sluggishness
Quoted 9 lines · Hamie
Quoted 7 lines · Alan Cox
Quoted 2 lines · Hamie
Is 100% CPU not excessive? IIRC my PIII-750 used to use less CPU doing the same job as quick, or even slightly faster...
Quoted 8 lines
Quoted 6 lines
PCMCIA IDE is PIO only so it burns CPU. This is one case where hyperthreading is nice. Cardbus IDE is a lot better but very little exists and we don't currently support hotplug IDE controllers.
Ah right. But would a CF memory card be cardbus anyway?
I've never seen a CF card that supported DMA (and I've worked with several brands). Compact Flash cards have several modes of operation and only one of this modes is "IDE-compatible".
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
And should it not use system CPU rather than user CPU?
Quoted 7 lines
Quoted 5 lines
Yes - but figure out please if the kernel or userspace is getting that wrong ;)
My apologies. It was gkrellm leading me up the garden path on that one... Copying about 100MB from a 512MB CF card (25+ photos from my camera) vmstat 5 reports 4% usercpu, 96% system cpu. And the response on the system is sluggish to say the least. (Moving the pointer in X is painful :). gkrell meanwhile on it's cpu graph shows about 30% system, and the rest as userCPU. No idea why, I guess till I find out I'll just regard gkrellm's cpu graph as a waste of space (To differentiate system & user cpu anyway :).
I think this is more of a scheduler/priorities problem. Maybe all the work that is being done with staircase / low-latency will help you on this :)
Signature · 2 lines
Paulo Marques - www.grupopie.com "In a world without walls and fences who needs windows and gates?"
Quoted 1 line · Paulo Marques
I've never seen a CF card that supported DMA (and I've worked with several brands). Compact Flash cards have several modes of operation and only one of this modes is "IDE-compatible".
The newer ones do. I've a SanDisk SDCFB-64-201-80 that hangs on boot because it reports that it supports DMA but the ide adapter I use does not connect the DMA request and grant signals. A work around is to boot with ide=nodma however this is system wide.
Pádraig.
Quoted 10 lines · Alan Cox
Quoted 1 line · Hamie
Is 100% CPU not excessive? IIRC my PIII-750 used to use less CPU doing the same job as quick, or even slightly faster...
PCMCIA IDE is PIO only so it burns CPU. This is one case where hyperthreading is nice. Cardbus IDE is a lot better but very little exists and we don't currently support hotplug IDE controllers.
Quoted 5 lines
Quoted 1 line
And should it not use system CPU rather than user CPU?
Yes - but figure out please if the kernel or userspace is getting that wrong ;)
He didn't mention seeing waitio in his stats (or I missed it) so he may be using old userspace tools which don't show waitio.
Should this show as system or waitio? Typically waitio time can be used for other thaings and this can't, so perhaps showing it as system is correct in this case.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me