From: Robert Hancock <hancockrwd@gmail.com>
To: "Artem S. Tashkinov" <t.artem@lycos.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Alan Stern <stern@rowland.harvard.edu>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel <linux-kernel@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 13:05:00 -0600 [thread overview]
Message-ID: <CADLC3L3bdTP8-X3ftMq1qxnL=LVDf7d5gbu2ZMH0pXg2AU8xjw@mail.gmail.com> (raw)
In-Reply-To: <384171828.66802.1367942365492.JavaMail.mail@webmail05>
On Tue, May 7, 2013 at 9: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).
I'm not sure if reading /proc/mtrr actually reads the registers out of
the CPU each time, or whether we just return the cached values we read
out during initial boot-up. If the latter, then this output isn't
really useful as there's no guarantee the values are still intact.
>
> In short, there's little to nothing that I can check.
>
> That bug report has nothing to do with my problem - my PC suspends and
> resumes more or less correctly - everything works (albeit some parts don't
> work as they should). That person also has a very outdated BIOS - 1904 from
> 08/15/2011. I wouldn't be surprised if BIOS update solved his problem.
>
> Best regards,
>
> Artem
next prev parent reply other threads:[~2013-05-07 19:05 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
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 [this message]
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='CADLC3L3bdTP8-X3ftMq1qxnL=LVDf7d5gbu2ZMH0pXg2AU8xjw@mail.gmail.com' \
--to=hancockrwd@gmail.com \
--cc=bhelgaas@google.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).