linux-kernel - Re: Poor desktop responsiveness with background I/O-operations

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: <1253517908.25640.37.camel@marge.simson.net>
Date:	Mon, 21 Sep 2009 09:25:08 +0200
From:	Mike Galbraith <efault@....de>
To:	Jan Kara <jack@...e.cz>
Cc:	Jiri Kosina <jkosina@...e.cz>,
	Ulrich Lukas <stellplatz-nr.13a@...enparkplatz.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Poor desktop responsiveness with background I/O-operations

On Mon, 2009-09-21 at 00:04 +0200, Jan Kara wrote:
> On Sun 20-09-09 22:22:20, Jiri Kosina wrote:
> > On Sun, 20 Sep 2009, Ulrich Lukas wrote:
> > 
> > > Test case:
> > > - 64-bit dual-core PC, SATA harddrive, plenty of free RAM
> > > - vanilla Linux 2.6.31, Kubuntu 9.10 packages, all software 64-bit
> > > 
> > > 
> > > How to reproduce:
> > > - start KDE/GNOME-session
> > > - open a terminal window and do as a non-root user:
> > >   dd if=/dev/zero of=/home/john-doe/testfile
> > >   (or dd if=/home/john-doe/big-testfile of=/dev/null)
> > > 
> > > - a real use scenario would be a daily disk-backup or the
> > >   simple extraction of a tarball containing slightly bigger files
> > > 
> > > 
> > > Observation:
> > > - The system becomes _really_ slow as described above; unusable for
> > >   any multimedia tasks.
> > 
> > I guess that switching from CFQ to deadline I/O scheduler improves the 
> > situation, right?
>   For example on my desktop, switching to deadline slightly improves the
> situation but the machine is still mostly unusable while dd is running...
> I'll try to debug it some more to see whether it can be somehow helped.

Datapoint:

echo 1 > /sys/block/$disk/queue/iosched/quantum seems to make a huge
difference.  Stock is 4.  (wisdom of setting it to 1? no idea)

This...
marge:/root/tmp # ./testo.sh
quantum is 4, setting to 1
dd if=3DMark2000.mkv of=/tmp/3DMark2000.mkv
204529+1 records in
204529+1 records out
104718895 bytes (105 MB) copied, 1.62672 s, 64.4 MB/s
perf sched record -o /tmp/mplayer-c2-c2.data (tmpfs)&
mplayer /tmp/3DMark2000.mkv&
dd if=/dev/zero of=crud-25859&

sleep 180
timing konsole -e exit

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

     173.615837  task-clock-msecs         #      0.031 CPUs
            431  context-switches         #      0.002 M/sec
             10  CPU-migrations           #      0.000 M/sec
           6314  page-faults              #      0.036 M/sec
      368422027  cycles                   #   2122.053 M/sec
      376283291  instructions             #      1.021 IPC
        5883195  cache-references         #     33.886 M/sec
         444333  cache-misses             #      2.559 M/sec

    5.597628358  seconds time elapsed

...is pretty typical, and a LOT better than the 60-70 seconds I was
seeing, or the minutes I sometimes saw when playing with evolution.

I still occasionally see some largish numbers though, and suspect that
depends on how much cache was evicted.

	-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/