gpartedbin and Xorg starve mkfs of CPU time.

[Dave Martin]

Binary package hint: gparted

There is no graphics acceleration on this board, so the rendering of the progress bar is done entirely on the CPU.

Note that renice can be used to increase the priority of mkfs; this improves things significantly.

ProblemType: Bug
Architecture: armel
DistroRelease: Ubuntu 9.04
MediaBuild: Ubuntu 9.04 "Jaunty Jackalope" - Release armel (20090421)
Package: gparted 0.4.3-0ubuntu1
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gparted
Uname: Linux 2.6.28-11-imx51 armv7l

[Jan Claeys (janc)]

I wonder if this happens on x86 with non-accelerated graphics too, or whether the used rendering code is very slow on armel for some reason...

[Hendrik Lönngren (hendrik0)]

Yes, this happens for me, too, on x86 with Intel 855GM video (for which graphics acceleration in broken, so it’s turned off). Even after renicing, mkfs gets only 5 to 10 % of CPU time. There should be a way to prevent gparted from doing this.

[Phillip Susi (psusi)]

mkfs should not need hardly any cpu time. Does renice actually make it take any less time to finish the format?

[Dave Martin (dave-martin-arm)]

I don't have a full Ubuntu filesystem in front of me right now, but running on a maverick/xfce-based linaro fs, I still observe some slowdown.

By default, mkfs.ext4 (for example) runs at +19 nice while gparted is making an ext4 filesystem on my SD card. Building the filesystem typically takes approximately 26 seconds in this configuration.

renicing to -19 or SCHED_FIFO, building the filesystem is quicker - about 21 seconds (which is close to the time taken to run mkfs.ext4 directly.)

The progress bar animation style has changed since I originally reported the bug (or xfce differs from the default gnome theme on this) - with xfce I now get a short bar sliding back and forth, instead of a full-width animated bar. This may affect the gparted/Xorg CPU load. The performance delta will vary between devices depending on memory bandwidth and bus contention etc. In my case, I don't seem to get the same amount of slowdown which I remember observing previously in Jaunty... but it's not the same software or hardware in this case.

I suggest that mkfs should not be run at positive nice on any platform - do you know what is causing this?

Cheers
---Dave

[Tobin Davis (gruemaster)]

I think this is more of an SD card issue than a mkfs or gparted issue. SD cards are inherently slower at writing than USB drives or real hard drives. While I can produce the slowness that is seen here on a beagle running natty, it actually takes the same amount of time as writing the SD card on my x86 desktop not using gparted.