Very high CPU usage during file operations

[Denis Rut'kov]

Finally, I know why 9.04 feels so slow compared to previous release.

Upon file operations (like copying) CPU usage goes up to almost 100%. What's worse, it doesn't show up in htop, as it's the kernel which uses CPU.

This bug is not related to the filesystem used - I tested it with ext3, ext4 and vfat fs.

I attach an oprofile report, which may or may not be useful to kernel hackers. The profiler ran for a short time while copying a 150 mb file from one ext4 partition to another. There were many calls to "copy_to_user_ll" and "copy_from_user_ll" routines.

[Denis Rut'kov (dendron2000)]

The problem still exists in kernels 2.6.28-12 and 2.6.29.

[Denis Rut'kov (dendron2000)]

Bug still present in Karmic (2.6.30 kernel).

[ABE3K (abe3k)]

I have the same problem with 2.6.28.11 on ubuntu 9.04 fully updated
a blank progress bar while copying large files with high cpu usage
I'm copying from ext3 to a fat32 usb flash memory

[SebastianG (basura-twominds)]

I have the same problem. What dump/logs do you need to troubleshoot?
100% CPU usage, jaunty is unuasable while doing file transfers from/to any medium (network, usb, sd memory).
I attached the lspci -v output.

[salva84 (salva-ms)]

same problem for me when copying to ntfs drive

[Francisco J. Yáñez (fjyaniez)]

Same problem here with kubuntu 9.04. I think this bug is similar to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/384139

Nobody gives a solution :(

[raamee (thiyadaram)]

same here, and no body solves it,,wats the thing with file operations,, pls come with solutions.

[cboese (boese)]

Same for me. Karmic, all updates, copy a single file (ca. 10GB) from FAT32, NTFS, ext3 to ext3. Both processors are gone and the system is barely usable.

[MaxFox (m-fox2k)]

same problem on clean install of ubuntu 10.04.
this problem exist starting from ubuntu 9.04 (upgrade from 8.10)

[kimus (kimus)]

Same problem in a clean install of ubuntu 10.04 and even copying files from the same partition (EXT4).
Load average goes to 5!!

If you need some help figuring this out please ask.
Thank You.

[Ralf Engels (ralf-engels)]

Same problem here.
Linux version 2.6.32-22-generic, 64 bit, using jfs

Large file copies make the system unusable. The cpu load goes up to 100%.

[ACMiller (mr-acmiller)]

I've got the same problem here as well, also since 9.04 through to 10.10. From my reading it seems that disabling AHCI in the BIOS (or switching to IDE) has fixed the problem for some, however I don't have that option in the BIOS of my laptop. Has anyone had success with this? Any other suggestions?

[sbela (gsbela)]

I have the same problem with lcuid, although I have a 67.9 MByte/sec speed copying from ext4 to a different disk ext4.
The two disks are attached to a Sata 2.0 port (the two drives are samsung 1TByte/32MByte cache).
For me it does not matter if the file size is huge or not, because if the file size is small than the speed is at 8-10MByte/s, which is sad.
The load average is 2.46 which is "acceptable".
I use my computer for desktop so it would be fine for me a little lower speed of copying, but a little more responsiveness.

It is very interesting that only a few people (13 bug reports as I see) have this issue.

Thanks for any suggestions.

[dvdmchl (dvd-mchl)]

The same problem here.
Have Ubuntu 10.10, kernel 2.6.35-27-generic-pae, was copying 15GB on ext4 from one directory to another on one volume.
5min load average was about 6.40, desktop unusable at the time.

[dvdmchl (dvd-mchl)]

Solved by changing IO scheduler to deadline.

cat /sys/block/sda/queue/scheduler
in brackets you'll see your current scheduler, it's probably cfg...

change it to deadline.

sudo doesn't work, need to be root

su -
echo deadline > /sys/block/sda/queue/scheduler

test it...

if it works then add the echo line to your rc.local or as a kernel parameter: elevator=deadline

Have tried the same copy job and load didn't go over 3...

[Alex Popovskiy (alex-popovskiy)]

The problem is still here for Ubuntu Natty /w 2.6.38 kernel, any intensive disk i/o makes the system very slow to respond, and when copying to/from external usb hdd it's even worse - mouse pointer freezes and system is completely unusable until that file operations finished.

[blitzter47 (blitzter47)]

I see CPU go to 100% also when downloading files from Internet at a speed of 800 KB/s, in addition of copying/moving files between partitions or hard drives.

Xubuntu 10.10 kernel 2.6.35-28-generic
-CPU AMD Athlon XP 2400+ (2,0 Ghz)
-685 MB of RAM
-Motherboard: SiS-741
Hard drives IDE P-ATA:
-QUANTUM FIREBALL CX13.0A : 13 GB, UDMA4
-MAXTOR 6L040J2 : 40 GB, UDMA 6
-WDC WD400BB-00DGA0 : 40 GB, UDMA 5

[blitzter47 (blitzter47)]

The program XFDESKTOP in Xubuntu (with XFCE desktop/environment) consumes all the CPU during file operation, according to the "top" file submitted previously. So I switched to GNOME desktop/environment and the problem is gone.

[penalvch (penalvch)]

Denis Rut'kov, thank you for reporting this and helping make Ubuntu better. Karmic reached EOL on April 30, 2011.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in a supported release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.

Please let us know your results. Thanks in advance.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]