linux-kernel - Re: I/O and pdflush

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: <6afc6d4a0908310624j47f9d8c7h47d98ecd95811883@mail.gmail.com>
Date:	Mon, 31 Aug 2009 10:24:20 -0300
From:	Fernando Silveira <fsilveira@...il.com>
To:	Wu Fengguang <fengguang.wu@...el.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: I/O and pdflush

On Sat, Aug 29, 2009 at 07:21, Wu Fengguang<fengguang.wu@...el.com> wrote:
> On Sat, Aug 29, 2009 at 06:12:47PM +0800, Wu Fengguang wrote:
>> On Sat, Aug 29, 2009 at 05:48:40AM +0800, Fernando Silveira wrote:
>> > On Sun, Jul 12, 2009 at 05:04, Wu Fengguang<fengguang.wu@...el.com> wrote:
>> > > On Sat, Jul 11, 2009 at 02:27:25PM -0300, Fernando Silveira wrote:
>> > >> I'm having a hard time with an application that writes sequentially
>> > >> 250GB of non-stop data directly to a solid state disk (OCZ SSD CORE
>> > >> v2) device and I hope you can help me. The command "dd if=/dev/zero
>> > >> of=/dev/sdc bs=4M" reproduces the same symptoms I'm having and writes
>> > >> exactly as that application does.
>>
>> Sure. Attached is a writeback debug patch. It will generate lots of
>> kernel messages. You can just stop your klogd, start your workload
>> and monitor the SSD writeback throughput via tools like iostat/dstat.
>
> Fernando, will you post the output of iostat/dstat too? Thanks!
> The ssd-no_dirty_buffer_with_random_192mb_writes.png is a good overview,
> however I'd like to also check out the numbers for each second :)
>
>> When it goes into the suboptimal 25MB/s state for several seconds, run
>>         dmesg > dmesg-writeback
>> and send me the log.
>>
>> And it is advised to turn on the kconfig option CONFIG_PRINTK_TIME=y.

Thanks for your help.

You can reach in the URL below a tarball which contains the data I
logged after patching the kernel with only your last patch.

http://rootshell.be/~swrh/ssd-tests/log-20090831_0908-MK020903042C0001B-prosar_fcc2-bs_4M.tar.gz

Each file contained in the tarball is described below:

- log-20090831_0908-MK020903042C0001B-prosar_fcc2-bs_4M-{0-ddv,1-table,2-plot}.*
  Logging statistics. The "0-ddv" file is the log of a modified
version of the dd(1) utility to print writing statistics after every
write(2), "1-table" is a table version of the "0-ddv" file parsed with
awk(1) and "2-plot" is the a plot image of the writing statistics.

- log-20090831_0908-MK020903042C0001B-prosar_fcc2-bs_4M-0-dstat.log
  The result of "dstat > dstat.log" executed ~3 seconds after "ddv" started.

- log-20090831_0908-MK020903042C0001B-prosar_fcc2-bs_4M-0-iostat.log
  The result of "iostat 1 > iostat.log" executed ~15 seconds after
"ddv" started.

- log-20090831_0908-MK020903042C0001B-prosar_fcc2-bs_4M-0-dmesg_writeback_{1..67}.log
  The result of "for i in {1..67}; do dmesg > dmesg-writeback-$i.log;
sleep 1; done" executed when "ddv" had written about 42GB of data.

- log-20090831_0908-MK020903042C0001B-prosar_fcc2-bs_4M-0-dmesg_writeback_{100..186}.log
  The result of "for i in {100..186}; do dmesg >
dmesg-writeback-$i.log; sleep 1; done" executed when "ddv" had written
about 51GB of data.

Please tell me if you need anything else. I could make a more
synchronized or informative logging output if you need.

Best regards,

-- 
Fernando Silveira <fsilveira@...il.com>
--
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/