Re: Big I/O latencies, except when iotop is hooked
From: Felipe Contreras
Date: Mon May 14 2012 - 05:08:21 EST
On Mon, May 14, 2012 at 10:59 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> 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
>> Can you send me or upload that iolog file?
> Hi Felipe,
> Any update?
Nope, sorry, my laptop got fried. I have a new one and I might be able
to test later today, I don't see why I would have any problems
reproducing this there, but lets see.
> 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.
As I already said, this also happens without encryption.
> 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:
I just do 'cryptsetup luksFormat' I'm not sure what is their default.
According to the manpage it's aes-cbc-essiv:sha256. I tried with
different --align-payload values, but none that actually improved the
Anyway, the problem is visible even with plain ext4.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/