Re: [PATCH v4 0/7] f/madivse(DONTNEED) support

[Ben Gamari <bgamari.foss@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On Tue, 7 Dec 2010 09:24:54 +0900, Minchan Kim <minchan.kim@gmail.com> 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 #2: patchv3-benchmark.tar.gz --]
[-- Type: application/octet-stream, Size: 14605 bytes --]