public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Artem S. Tashkinov" <t.artem@lycos.com>
To: torvalds@linux-foundation.org
Cc: bhelgaas@google.com, linux-kernel@vger.kernel.org
Subject: Re: Abysmal HDD/USB write speed after sleep on a UEFI system
Date: Tue, 12 Feb 2013 20:13:33 +0000 (UTC)	[thread overview]
Message-ID: <1661570408.42886.1360700013207.JavaMail.mail@webmail03> (raw)
In-Reply-To: CA+55aFyK1zhNerWHkd=FMMeTH_sfiL4sBFq00y4n5eAJ88Z_cA@mail.gmail.com

Feb 13, 2013 01:32:53 AM, Linus Torvalds wrote:
On Tue, Feb 12, 2013 at 10:29 AM, Artem S. Tashkinov 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..

I've just plugged and unplugged my USB stick into all available hubs
(including a USB3 one, that is xhci_hcd) and I've got the same write speed
on all of them - around 930KB/sec (quite a weird number - as if I'm on USB
1.1) - lsusb says I'm happily running ehci_hcd/2p, 480M and xhci_hcd/2p,
5000M.

The only pattern that I see here is that write speed to real devices degrades,
tmpfs write speed stays the same:

$ dd if=/dev/zero of=test bs=32M count=32
32+0 records indegrade
32+0 records out
1073741824 bytes (1.1 GB) copied, 0.296323 s, 3.6 GB/s

Best regards,

Artem

  reply	other threads:[~2013-02-12 20:13 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <587312497.6453.1360650312498.JavaMail.mail@webmail01>
2013-02-12 17:29 ` Abysmal HDD/USB write speed after sleep on a UEFI system Linus Torvalds
2013-02-12 18:29   ` Artem S. Tashkinov
2013-02-12 19:32     ` Linus Torvalds
2013-02-12 20:13       ` Artem S. Tashkinov [this message]
2013-02-13  4:26         ` Bjorn Helgaas
2013-02-19 16:22           ` Alan Stern
2013-02-25 21:57             ` Bjorn Helgaas
2013-02-26  6:35               ` Artem S. Tashkinov
2013-02-26 18:46                 ` Bjorn Helgaas
2013-02-26 19:14                   ` Artem S. Tashkinov
2013-03-07  0:17                     ` Bjorn Helgaas
2013-04-26 21:36                       ` Bjorn Helgaas
2013-04-27 10:10                         ` Artem S. Tashkinov
2013-04-30  4:47                           ` Bjorn Helgaas
2013-05-01  4:19                             ` Robert Hancock
2013-05-07 15:25                               ` Bjorn Helgaas
2013-05-07 15:59                                 ` Artem S. Tashkinov
2013-05-07 16:27                                   ` Bjorn Helgaas
2013-05-07 18:50                                     ` Artem S. Tashkinov
2013-05-07 18:54                                       ` Bjorn Helgaas
2013-05-07 19:05                                   ` Robert Hancock
2013-05-07 20:20                                     ` Bjorn Helgaas
2013-05-07 21:48                                       ` Patrik Jakobsson
2013-05-07 22:02                                         ` Bjorn Helgaas
2013-05-07 22:25                                           ` Patrik Jakobsson
2013-05-08  8:37                                             ` Artem S. Tashkinov
2013-05-08  8:54                                               ` Patrik Jakobsson
2013-05-08 13:43                                               ` Phillip Susi
2013-05-08  8:31                                           ` Artem S. Tashkinov
2013-05-07 16:12                                 ` Phillip Susi
2013-07-10 17:25   ` hyphop
2013-07-10 20:50     ` Bjorn Helgaas
2013-02-10 10:43 Artem S. Tashkinov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1661570408.42886.1360700013207.JavaMail.mail@webmail03 \
    --to=t.artem@lycos.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox