Very interesting! I immediately tried that out on my Jaunty install based on an ext3 partition.
The standard test procedure I use is to first launch this to load the system: tar cf 1.tar /usr Then I launch and quit Firefox several times, open its menus, wait some time before reattempts... while the tar command is still working. So, I first launched this: schedtool -a 0 -e tar cf 1.tar /usr Then I tried launching, quiting and using Firefox. The outcome was significantly better! So it works on my machine too... Yet it wasn't as good as on the Jaunty install based on ext4. On that one, the fact the tar command is proceeding virtually has no impact on Firefox (except if waiting till the tar command leads the Firefox files and libraries to be erased from the disk cache, of course, but even so Firefox still starts at an usual speed). Now something strange... I tried to impose (on the ext3 install) which processor Firefox will use: schedtool -a 0 -e firefox schedtool -a 1 -e firefox In both cases, using either the same processor as the tar command or the other, the result was worse! It was worst when using the same processor... then Firefox was completely unusable. On the ext4 install, I tried launching the tar command and Firefox on the same and on a different processor. In all cases Firefox started instantly and behaved fluently, as if no tar command was running. -- [jaunty] cpu scheduling is not optimized for multitask https://bugs.launchpad.net/bugs/363663 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
