lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1253475521.9224.43.camel@marge.simson.net>
Date:	Sun, 20 Sep 2009 21:38:41 +0200
From:	Mike Galbraith <efault@....de>
To:	Ulrich Lukas <stellplatz-nr.13a@...enparkplatz.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Poor desktop responsiveness with background I/O-operations

On Sun, 2009-09-20 at 10:50 +0200, Ulrich Lukas wrote:
> Arjan van de Ven wrote:
> > can you try the following two things?
> > 
> > echo 4096 > /sys/block/sda/queue/nr_requests
> > for i in `pidof kjournald` ; do ionice -c1 -p $i ; done
> 
> I tried this just now, but it doesn't change things much. I can do a
> more testing later today.

Try ionice -c3 for your dd.

> > I assume you're using CFQ.
> 
> Yes, it's CFQ. (see .config of my previous posting)
> 
> Filesystem is EXT4.

Mine is ext3.

I can easily reproduce pain.  The attached cheezy test script, when run
back to back with no args (stock IO), regularly produces beauties:

 Performance counter stats for 'sh -c konsole -e exit':

     257.670601  task-clock-msecs         #      0.004 CPUs
           1036  context-switches         #      0.004 M/sec
             30  CPU-migrations           #      0.000 M/sec
           6317  page-faults              #      0.025 M/sec
      471734719  cycles                   #   1830.767 M/sec
      393365060  instructions             #      0.834 IPC
        7849464  cache-references         #     30.463 M/sec
        1038976  cache-misses             #      4.032 M/sec

   65.766937233  seconds time elapsed

Yup, a full minute to get a binary loaded and fired up.  Seems it and
others get evicted by the VM.  Getting whatever back into ram is painful
to listen to (poor disk/me.. seek latency eating MUCH time).

Calling script back to back with args 1 (realtime foreground) 3 (idle
background) does best:

 Performance counter stats for 'sh -c konsole -e exit':

     169.915036  task-clock-msecs         #      0.077 CPUs
            439  context-switches         #      0.003 M/sec
              9  CPU-migrations           #      0.000 M/sec
           6314  page-faults              #      0.037 M/sec
      363128252  cycles                   #   2137.117 M/sec
      367410945  instructions             #      1.012 IPC
        5822302  cache-references         #     34.266 M/sec
         437189  cache-misses             #      2.573 M/sec

    2.213079979  seconds time elapsed

Args 2 (best effort foreground) and 3 (idle background);

 Performance counter stats for 'sh -c konsole -e exit':

     176.689856  task-clock-msecs         #      0.015 CPUs
            357  context-switches         #      0.002 M/sec
             15  CPU-migrations           #      0.000 M/sec
           6314  page-faults              #      0.036 M/sec
      374861947  cycles                   #   2121.582 M/sec
      368929476  instructions             #      0.984 IPC
        5806286  cache-references         #     32.861 M/sec
         496651  cache-misses             #      2.811 M/sec

   12.036165968  seconds time elapsed

	-Mike

Download attachment "testo.sh" of type "application/x-shellscript" (1703 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ