On Tue, 7 Dec 2010 09:24:54 +0900, Minchan Kim <minchan.kim@xxxxxxxxx> wrote: > Sorry missing you in Cc. > > Ben. Could you test this series? > You don't need to apply patch all so just apply 2,3,4,5. > This patches are based on mmotm-12-02 so if you suffered this patches > from applying your kernel, I can help you. :) > I am very sorry for my lack of responsiveness. It's the last week of the semester so things have been a bit busy. Nevertheless, I did do some testing on v3 of the patch last week. Unfortunately, the results weren't so promising, although this very well could be due to problems with my test. For both patched and unpatched rsyncs and kernels I did roughly the following, $ rm -Rf $DEST $ cat /proc/vmstat > vmstat-pre $ time rsync -a $SRC $DEST $ cat /proc/vmstat > vmstat-post $ time rsync -a $SRC $DEST $ cat /proc/vmstat > vmstat-post-warm Where $DEST and $SRC both reside on local a SATA drive (hdparm reports read speeds of about 100MByte/sec). I ran this (test.sh) three times on both a patched kernel (2.6.37-rc3) and an unpatched kernel (2.6.37-rc3-mm1). The results can be found in the attached tarball. Judging by the results, something is horribly wrong. The "drop" (patched rsync) runtimes are generally 3x longer than the "nodrop" (unpatched rsync) runtimes in the case of the patched kernel. This suggests that rsync is doing something I did not anticipate. I'll redo the test tonight with v4 of the patch and will investigate the source of the performance drop as soon as the school-related workload subsides. Cheers, - Ben
Attachment:
patchv3-benchmark.tar.gz
Description: Binary data