linux-kernel - Re: Big I/O latencies, except when iotop is hooked

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: <201205140859.52921.arnd@arndb.de>
Date:	Mon, 14 May 2012 08:59:52 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Big I/O latencies, except when iotop is hooked

On Thursday 10 May 2012, Arnd Bergmann wrote:
> 176 is extremely bad, yes. A good value would be between 1 and 3.
> The algorithm is probably not 'la' but 'dl' and the page size (-b)
> could be smaller -- you have to test by passing '--blocksize=1024' to
> the --open-au test and see where it starts getting drastically
> smaller (if 4KB gives you about half the throughput of 8KB,
> 8KB is the page size). Those two can make the result better.
> 
> As I said, the erase block size is more likely to be 4MB, which
> will make the flashsim result worse.
> 
> Does flashsim give a better number for a trace taken with iotop
> running?
> 
> Can you send me or upload that iolog file?

Hi Felipe,

Any update? I'd really be interested in the trace file so that we
can look at data of a real-world case that hurts. I've discussed
your problem in the Linaro storage team meeting, and the question
came up whether this only happens with encryption enabled.

Which kind of encryption method do you actually use? Depending
on how the encryption is implemented, two things could possibly
go wrong that would not happen without it:

* A superblock is added to the partition that contains some metadata
relating to the encryption, so all data is offset by a few sectors,
turning a perfectly aligned partition into a misaligned one.

* All write accesses are sent as 4kb operations to the device rather
than getting at least flash-page-sized (e.g. 16kb) I/O most of the
time.

	Arnd
--
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/