linux-kernel - Re: Abysmal HDD/USB write speed after sleep on a UEFI system

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]

Date:	Tue, 12 Feb 2013 11:32:31 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Artem S. Tashkinov" <t.artem@...os.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Abysmal HDD/USB write speed after sleep on a UEFI system

On Tue, Feb 12, 2013 at 10:29 AM, Artem S. Tashkinov <t.artem@...os.com> wrote:
> Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote:
>>
>>A few things to try to pinpoint:
>>
>> (a) Is it *only* write performance that suffers, or is it other
>>performance too? Networking (DMA? Perhaps only writing *to* the
>>network?)? CPU?
>
> I've tested hdpard -tT --direct and the output on boot and after suspend
> is quite similar.
>
> I've also checked my network read/write speed, and it's the same
> ~ 100MBit/sec (I have no 1Gbit computers on my network
> unfortunately).

Ok. So it really sounds like just USB and HD writes. Which is quite
odd, since they have basically nothing in common I can think of
(except the obvious block layer issues).

>> (b) the fact that it apparently happens with both SATA and USB
>>implies that it  's neither, and is more likely something core like
>>memory speed (mtrr, caching) or PCI (DMA, burst sizes, whatever).
>
> I've no idea, please, check my bug report where I've just added lots of
> information including a diff between on boot and after suspend.

I'm not seeing anything particularly interesting there.

Except why/how did the MSI address/data change for the SATA
controller? The irq itself hasn't changed.. There's probably some sane
reason for that too (it's an odd encoding, maybe they code for the
same thing), and there's nothing like that for USB, so...

And if it was irq problems, I'd expect you to see it more for reads
than for writes anyway. Along with a few messages about missed irqs
and whatever.

I'm stumped, and have no ideas. I can't even begin to guess how this
would happen. One thing to try is if it happens for all USB ports (you
have multiple controllers) and I assume performance doesn't come back
if you unplug and replug the USB disk..

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