Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758900Ab3EGUU4 (ORCPT ); Tue, 7 May 2013 16:20:56 -0400 Received: from mail-oa0-f50.google.com ([209.85.219.50]:47273 "EHLO mail-oa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753823Ab3EGUUx (ORCPT ); Tue, 7 May 2013 16:20:53 -0400 MIME-Version: 1.0 In-Reply-To: References: <337833384.57445.1361860509194.JavaMail.mail@webmail08> <569718148.80620.1361906088301.JavaMail.mail@webmail13> <771333906.75854.1367057440028.JavaMail.mail@webmail08> <518097B8.4020402@gmail.com> <384171828.66802.1367942365492.JavaMail.mail@webmail05> From: Bjorn Helgaas Date: Tue, 7 May 2013 13:20:32 -0700 Message-ID: Subject: Re: Abysmal HDD/USB write speed after sleep on a UEFI system To: Robert Hancock Cc: "Artem S. Tashkinov" , Alan Stern , Linus Torvalds , linux-kernel , "linux-pci@vger.kernel.org" , "Rafael J. Wysocki" , Phillip Susi Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2588 Lines: 52 On Tue, May 7, 2013 at 12:05 PM, Robert Hancock wrote: > On Tue, May 7, 2013 at 9:59 AM, Artem S. Tashkinov 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. Good point. From what I can tell, on Artem's system with "CPU0: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz," we would be using generic_mtrr_ops, and generic_get_mtrr() appears to read from the MSRs, so I think it should be useful. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/