Ubuntu Wiki

Summary

Bug #131094[1] reports worse interactive behaviour with Gutsy kernel as compared to Feisty. Hence this test was performed to try to interactivity or lack there of between 2.6.22 and 2.6.20 kernels.

[1] https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/131094

Test setup

• HW: IBM T41p laptop, 512Mb RAM
• OS: Gutsy Tribe 5 updated to latest as of 26.09.07, 2.6.22-12 kernel
• 2.6.20 kernel installed from Feisty repository

• hackbench from http://developer.osdl.org/craiger/hackbench/

• Test script#io-test.sh to automate collection of data

• Test script#ioload.sh to create background disk I/O

Description of test

1. Run trackerd and a dd process to create background disk I/O. Use hackbench to create cpu load on the system

2. Use the system for normal interactive tasks while running the script e.g. Browsing, streaming music, typing in multiple terminals, etc.
3. hackbench is run 10 times for each size of process group, the largest reading is discarded and the average is taken.

Observations

1. trackerd creates Disk I/O, but does very aggressive backoff in presence of other IO/cpu load - Good!
2. hackbench creates CPU load and exercises context switch times.
3. Moving the mouse around during these tests give a fair estimate of 'interactivity'. The mouse start faltering badly after 40 processes in the Feisty tests. The motion remained smooth (save for occassional glitches) in the Gutsy tests.

Results

GutsyFeistySchedulerShootout/scheduler-shootout.ods

• Graph shows Gutsy's scheduler performing better as the number of hackbench processes increases beyond 40.
• Infact, if we didn't discard the largest reading of each set, Feisty would show up much worse.
• Feisty kernel's scheduler struggled after 40 processes to keep interactive applications happy - mouse was very jerky, commands typed to terminal took a while to show up, etc.

Recommendation

1. According the mjg59, upstream has support for power policy, we should sync to uptream
2. This study was done based on the reports in the bug #131094 about interactivity during disk I/O, but it seems that the real problem is one type of disk I/O (e.g. trackerd indexing) causing problem with other disk I/O (e.g. file saving). So this test will be redone.

Misc. Links

1. http://kerneltrap.org/node/431

2. http://kerneltrap.org/Linux/Additional_CFS_Benchmarks

3. http://developer.osdl.org/craiger/hackbench/

Test script

# Generate background I/O
# Run as 'ioload.sh &' and kill it at the end

TMPFILE=/tmp/foo

rm -f $TMPFILE > /dev/null 2>&1

while ((1)); do
    nice -0 dd if=/dev/zero of=$TMPFILE bs=100k count=4000 > /dev/null 2>&1
    rm -f $TMPFILE
done

LOG=${1:?"Usage: $0 logfile-name"}
TMPFILE="/tmp/foo"

echo "#Script start: `date +"%d%m%y %H%M%S"`" >> $LOG

# Clean up environment
echo "Cleaning up..."
rm -f $TMPFILE > /dev/null 2>&1
killall trackerd > /dev/null 2>&1

sleep 10

echo "#Trackerd started: `date +"%d%m%y %H%M%S"`" >> $LOG
# Trackerd is configured to start indexing after 30s, reindex to simulate load
echo "Starting trackerd..."
trackerd -R > /dev/null 2>&1 &
sleep 35

# Background load
ioload.sh &

echo "#Start hackbench: `date +"%d%m%y %H%M%S"`" >> $LOG
for((i=10; i < 100; i+=10)); do
    echo "      Number of process groups: $i" >> $LOG
    for((j=1; j < 10; j++)); do
        echo "          Iteration $j: `nice -0 hackbench -pipe $i`" >> $LOG;
    done;
done


echo "#Done: `date +"%d%m%y %H%M%S"`" >> $LOG
killall ioload.sh
killall trackerd

echo "Done\n"

CategoryHomepage