linux-kernel - Re: unfair io behaviour for high load interactive use still present in 2.6.31

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Sat, 26 Sep 2009 12:35:47 -0700 (PDT)
From:	Daniel J Blueman <daniel.blueman@...il.com>
To:	Tobias Oetiker <tobi@...iker.ch>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: unfair io behaviour for high load interactive use still present 
	in 2.6.31

On Sep 16, 9:00 am, Tobias Oetiker <t...@...iker.ch> wrote:
> Today Corrado Zoccolo wrote:
> > On Tue, Sep 15, 2009 at 11:07 PM, Tobias Oetiker <t...@...iker.ch> wrote:
> > > Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
> > > ---------------------------------------------------------------------------------------------------------
> > > dm-18             0.00     0.00    0.00 2566.80     0.00    10.03     8.00  2224.74  737.62   0.39 100.00
> > > dm-18             0.00     0.00    9.60  679.00     0.04     2.65     8.00   400.41 1029.73   1.35  92.80
> > > dm-18             0.00     0.00    0.00 2080.80     0.00     8.13     8.00   906.58  456.45   0.48 100.00
> > > dm-18             0.00     0.00    0.00 2349.20     0.00     9.18     8.00  1351.17  491.44   0.43 100.00
> > > dm-18             0.00     0.00    3.80  665.60     0.01     2.60     8.00   906.72 1098.75   1.39  93.20
> > > dm-18             0.00     0.00    0.00 1811.20     0.00     7.07     8.00  1008.23  725.34   0.55 100.00
> > > dm-18             0.00     0.00    0.00 2632.60     0.00    10.28     8.00  1651.18  640.61   0.38 100.00
>
> > Good.
> > The high await is normal for writes, especially since you get so many
> > queued requests.
> > can you post the output of "grep -r .  /sys/block/_device_/queue/" and
> > iostat for your real devices?
> > This should not affect reads, that will preempt writes with cfq.
>
> /sys/block/sdc/queue/nr_requests:128
> /sys/block/sdc/queue/read_ahead_kb:128
> /sys/block/sdc/queue/max_hw_sectors_kb:2048
> /sys/block/sdc/queue/max_sectors_kb:512
> /sys/block/sdc/queue/scheduler:noop anticipatory deadline [cfq]
> /sys/block/sdc/queue/hw_sector_size:512
> /sys/block/sdc/queue/logical_block_size:512
> /sys/block/sdc/queue/physical_block_size:512
> /sys/block/sdc/queue/minimum_io_size:512
> /sys/block/sdc/queue/optimal_io_size:0
> /sys/block/sdc/queue/rotational:1
> /sys/block/sdc/queue/nomerges:0
> /sys/block/sdc/queue/rq_affinity:0
> /sys/block/sdc/queue/iostats:1

> /sys/block/sdc/queue/iosched/quantum:4

As Mike points out [1], it may be worth trying a small quantum, though
the benefit may depend on the behaviour of your SCSI RAID controller.

--- [1]

http://groups.google.com/group/linux.kernel/browse_thread/thread/49d2360a22af8898/60022a7e287af096#60022a7e287af096
--
Daniel J Blueman
--
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/