From: Bjorn Helgaas <bhelgaas@google.com>
To: "Artem S. Tashkinov" <t.artem@lycos.com>
Cc: Robert Hancock <hancockrwd@gmail.com>,
Alan Stern <stern@rowland.harvard.edu>,
Linus Torvalds <torvalds@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
psusi@ubuntu.com
Subject: Re: Abysmal HDD/USB write speed after sleep on a UEFI system
Date: Tue, 7 May 2013 09:27:09 -0700 [thread overview]
Message-ID: <CAErSpo75ittZE8pS0e6UGvVY3KXe5+_O=4AMU3ToWVyK9wwZ8g@mail.gmail.com> (raw)
In-Reply-To: <384171828.66802.1367942365492.JavaMail.mail@webmail05>
On Tue, May 7, 2013 at 8:59 AM, Artem S. Tashkinov <t.artem@lycos.com> wrote:
> May 7, 2013 09:25:40 PM, Bjorn Helgaas wrote:
>> [+cc Phillip]
>>
>>> I would suspect that Windows' complaint about the BIOS mucking up the MTRRs
>>> is likely the best hint. Likely Windows is detecting the problem and fixing
>>> it up on resume, thus it only complains about "reduced resume performance".
>>> If the MTRRs are messed up, then quite likely parts of RAM have become
>>> uncacheable, causing performance to get randomly slaughtered in various
>>> ways.
>>>
>>> From looking at the code it's not clear if we are checking/restoring the
>>> MTRR contents after resume. If not, maybe we should be.
>>
>>I agree; the MTRR warning is a good hint. Artem?
>>
>>Phillip, I cc'd you because you have similar hardware and your
>>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1131468 report is
>>slightly similar. Have you seen anything like this "reduced
>>performance after resume" issue? If so, can you collect /proc/mtrr
>>contents before and after suspending?
>>
>
> Like Robert Hancock correctly noted the Linux kernel lacks the code to check
> for MTTR changes after resume - I'm not a kernel hacker to write such a code ;-)
>
> Likewise there's no code to see if RAM pages have become uncacheable - i.e
> I've no idea how to check it either.
>
> According to /proc/mttr nothing changes on resume - only Windows detects
> the discrepancy between MTTR regions on resume. dmesg contains no warnings
> or errors (aside from usual ACPI SATA warnings - but they happen right on
> boot - so I highly doubt the ACPI or SATA layers can be the culprit, since USB
> exhibits a similar performance degradation).
>
> In short, there's little to nothing that I can check.
I'm not trying to be ungrateful, but maybe you could actually collect
the info we've asked for and attach it to the bugzilla. It's hard for
me to get excited about digging into this when all I see is "nothing
changes in MTRR" and "it's probably not X." I really need some
concrete data to help rule things out and suggest other things to
investigate.
Maybe we won't be able to make progress on this until other people
start hitting similar issues and we can find patterns.
Bjorn
next prev parent reply other threads:[~2013-05-07 16:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <587312497.6453.1360650312498.JavaMail.mail@webmail01>
[not found] ` <CA+55aFyscOeZUPaYj_-QYgjADPD59+=c5aMvtpPEnd1tmpUGiA@mail.gmail.com>
[not found] ` <1362466310.40337.1360693775935.JavaMail.mail@webmail03>
[not found] ` <CA+55aFyK1zhNerWHkd=FMMeTH_sfiL4sBFq00y4n5eAJ88Z_cA@mail.gmail.com>
[not found] ` <1661570408.42886.1360700013207.JavaMail.mail@webmail03>
2013-02-13 4:26 ` Abysmal HDD/USB write speed after sleep on a UEFI system 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 [this message]
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
[not found] ` <1373477126220-681610.post@n7.nabble.com>
2013-07-10 20:50 ` Bjorn Helgaas
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='CAErSpo75ittZE8pS0e6UGvVY3KXe5+_O=4AMU3ToWVyK9wwZ8g@mail.gmail.com' \
--to=bhelgaas@google.com \
--cc=hancockrwd@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=psusi@ubuntu.com \
--cc=rjw@sisk.pl \
--cc=stern@rowland.harvard.edu \
--cc=t.artem@lycos.com \
--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;
as well as URLs for NNTP newsgroup(s).