linux-kernel - Re: [git patches] libata updates for 3.3

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, 17 Jan 2012 13:16:33 +0800
From:	Lin Ming <ming.m.lin@...el.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jeff Garzik <jeff@...zik.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-ide@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git patches] libata updates for 3.3

On Mon, 2012-01-16 at 11:55 -0800, Linus Torvalds wrote:
> On Mon, Jan 16, 2012 at 11:29 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > and I do think that resume used to be faster in v3.2 than it is even
> > with your patch. But maybe that's some rose-colored glasses.
> >
> > I'll recompile an old kernel to check.
> 
> Confirmed.
> 
> Plain v3.2 really *is* faster than current git, even current git with
> your patch.
> 
> In v3.2 I get this:
> 
>  [   92.035600] ata_piix 0000:00:1f.2: PCI INT B -> GSI 19 (level,
> low) -> IRQ 19
>  [   92.035610] ata_piix 0000:00:1f.2: setting latency timer to 64
>  [   92.036213] sd 0:0:0:0: [sda] Starting disk
>  [   93.060471] ata2.00: failed to resume link (SControl 0)
>  [   93.379963] ata1.01: failed to resume link (SControl 0)
>  [   93.535802] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>  [   93.535815] ata1.01: SATA link down (SStatus 0 SControl 0)
>  [   93.543968] ata1.00: ACPI cmd ef/03:46:00:00:00:a0 (SET FEATURES)
> filtered out
>  [   93.544747] ata1.00: configured for UDMA/100
>  [   93.916453] PM: resume of devices complete after 1883.974 msecs
>  [   93.916677] PM: Finishing wakeup.
>  [   94.086800] ata2.01: failed to resume link (SControl 0)
>  [   94.098408] ata2.00: SATA link down (SStatus 4 SControl 0)
>  [   94.098429] ata2.01: SATA link down (SStatus 0 SControl 0)
> 
> while current git (with your patch) gives me
> 
>  [  108.115373] ata_piix 0000:00:1f.2: setting latency timer to 64
>  [  109.142010] ata2.00: failed to resume link (SControl 0)
>  [  109.462004] ata1.01: failed to resume link (SControl 0)
>  [  109.618065] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>  [  109.618078] ata1.01: SATA link down (SStatus 0 SControl 0)
>  [  109.626242] ata1.00: ACPI cmd ef/03:46:00:00:00:a0 (SET FEATURES)
> filtered out
>  [  109.627060] ata1.00: configured for UDMA/100
>  [  109.627240] sd 0:0:0:0: [sda] Starting disk
>  [  110.170015] ata2.01: failed to resume link (SControl 0)
>  [  110.181480] ata2.00: SATA link down (SStatus 4 SControl 0)
>  [  110.181496] ata2.01: SATA link down (SStatus 0 SControl 0)
>  [  110.182124] PM: resume of devices complete after 2066.945 msecs
>  [  110.224533] PM: Finishing wakeup.
> 
> so old kernels used to be a tiny bit faster despite not doing that
> async thing (still slower than I'd like: I'd think that we should be

No, old kernel did that async thing.

Old kernel embedded the ata port suspend/resume code in host
suspend/resume code and host has async suspend enabled.

I split the ata port suspend/resume code out.

ata: add ata port system PM callbacks
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=5ef4108

But ata port async suspend was not enabled in above patch.
So I think this is a regression.

Thanks,
Lin Ming

> able to resume devices in less than a second, but I don't know where
> all the time goes)
> 
>              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/