From: Matthew Garrett <mjg59@srcf.ucam.org> To: Ingo Molnar <mingo@elte.hu> Cc: LKML <linux-kernel@vger.kernel.org>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, pm list <linux-pm@lists.linux-foundation.org> Subject: Re: Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Mon, 8 Jun 2009 15:35:13 +0100 [thread overview] Message-ID: <20090608143513.GB16752@srcf.ucam.org> (raw) In-Reply-To: <20090608142450.GE14234@elte.hu> On Mon, Jun 08, 2009 at 04:24:50PM +0200, Ingo Molnar wrote: > * Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > eSATA is pretty common now. > > [ And 99% of the CPUs have an IDT still 99.9% of the users dont know > what it is :) ] Users know that there's a socket on the front of their computer that they can plug a hard drive into, and if that doesn't work then they're going to be upset. > > The problem with this kind of default is that you get people who > > are confused that their hardware doesn't work. > > If the hardware 'doesnt work' that is a kernel bug. Hardware that > _cannot be suspended_ safely (physically) should not be > auto-suspended, of course. So, like I said, the kernel can't automatically suspend AHCI unless it's received some information from elsewhere that tells it it's ok to. The kernel can't know if there's an eSATA port or not. > > If the kernel doesn't have enough information to make a decision > > it should err on the side of functionality - we're talking about > > fairly low-level power savings, but potentially several years of > > aggregate confusion on the part of users. > > the difference between a 10W and a 1W footprint is a long series of > 'low-level power savings'. > > If users are getting confused and if hardware gets broken then tha's > a plain bug and the wrong path is being walked. Yes. And powersaving is a tradeoff between functionality and power consumption. The kernel doesn't know what level of functionality a given user requires. It *can't* know that itself. > > Users are generally ok at realising correlation between a setting > > change and something no longer working, so as long as you provide > > that they'll be happy. I agree that this sucks. What we actually > > want is some means of reliably identifying whether a port is > > hotplug or not, but eSATA makes this very difficult. > > Is it impossible? To the best of my knowledge, yes. > > My argument is "Hardware should work, and if the kernel default is > > for it to be broken then the default is wrong". We went through > > this for USB autosuspend. Userspace simply has more available > > information than the kernel, and it's not just a matter of static > > configuration (though that may be part of it). For instance, > > Oliver's example of screensavers and USB keyboards. If nothing's > > paying attention to volume keys (or if the keyboard doesn't have > > any) then you can enable remote wakeup and suspend the keyboard. > > If something /is/ paying attention to volume keys, you can't do > > that. That's the kind of case I'm discussing. > > See my reply to Oliver. This is really advocating a broken model of > device usage. That volume key usage dependency is being hidden from > the kernel, and then you want to kludge it around by pushing suspend > functionality to user-space? That way lies madness. The proper way > is to close the device if it's not used by anything. Then the kernel > can auto-suspend it just like it could auto-suspend network > interfaces that are not in use, or like it could auto-suspend a > dislay port that has no monitor or other output device attached. No, we can't just close it - then we won't get notification that a key's been hit in order to unlock the screensaver. Yes, we can greatly expand the userland-visible interface to every piece of hardware in order to make this work, but that's a huge amount of effort to avoid a model where userspace sets some tunables appropriately. -- Matthew Garrett | mjg59@srcf.ucam.org
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Garrett <mjg59@srcf.ucam.org> To: Ingo Molnar <mingo@elte.hu> Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Alan Stern <stern@rowland.harvard.edu>, pm list <linux-pm@lists.linux-foundation.org>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Magnus Damm <magnus.damm@gmail.com> Subject: Re: Run-time PM idea (was: Re: [linux-pm] [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Mon, 8 Jun 2009 15:35:13 +0100 [thread overview] Message-ID: <20090608143513.GB16752@srcf.ucam.org> (raw) In-Reply-To: <20090608142450.GE14234@elte.hu> On Mon, Jun 08, 2009 at 04:24:50PM +0200, Ingo Molnar wrote: > * Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > eSATA is pretty common now. > > [ And 99% of the CPUs have an IDT still 99.9% of the users dont know > what it is :) ] Users know that there's a socket on the front of their computer that they can plug a hard drive into, and if that doesn't work then they're going to be upset. > > The problem with this kind of default is that you get people who > > are confused that their hardware doesn't work. > > If the hardware 'doesnt work' that is a kernel bug. Hardware that > _cannot be suspended_ safely (physically) should not be > auto-suspended, of course. So, like I said, the kernel can't automatically suspend AHCI unless it's received some information from elsewhere that tells it it's ok to. The kernel can't know if there's an eSATA port or not. > > If the kernel doesn't have enough information to make a decision > > it should err on the side of functionality - we're talking about > > fairly low-level power savings, but potentially several years of > > aggregate confusion on the part of users. > > the difference between a 10W and a 1W footprint is a long series of > 'low-level power savings'. > > If users are getting confused and if hardware gets broken then tha's > a plain bug and the wrong path is being walked. Yes. And powersaving is a tradeoff between functionality and power consumption. The kernel doesn't know what level of functionality a given user requires. It *can't* know that itself. > > Users are generally ok at realising correlation between a setting > > change and something no longer working, so as long as you provide > > that they'll be happy. I agree that this sucks. What we actually > > want is some means of reliably identifying whether a port is > > hotplug or not, but eSATA makes this very difficult. > > Is it impossible? To the best of my knowledge, yes. > > My argument is "Hardware should work, and if the kernel default is > > for it to be broken then the default is wrong". We went through > > this for USB autosuspend. Userspace simply has more available > > information than the kernel, and it's not just a matter of static > > configuration (though that may be part of it). For instance, > > Oliver's example of screensavers and USB keyboards. If nothing's > > paying attention to volume keys (or if the keyboard doesn't have > > any) then you can enable remote wakeup and suspend the keyboard. > > If something /is/ paying attention to volume keys, you can't do > > that. That's the kind of case I'm discussing. > > See my reply to Oliver. This is really advocating a broken model of > device usage. That volume key usage dependency is being hidden from > the kernel, and then you want to kludge it around by pushing suspend > functionality to user-space? That way lies madness. The proper way > is to close the device if it's not used by anything. Then the kernel > can auto-suspend it just like it could auto-suspend network > interfaces that are not in use, or like it could auto-suspend a > dislay port that has no monitor or other output device attached. No, we can't just close it - then we won't get notification that a key's been hit in order to unlock the screensaver. Yes, we can greatly expand the userland-visible interface to every piece of hardware in order to make this work, but that's a huge amount of effort to avoid a model where userspace sets some tunables appropriately. -- Matthew Garrett | mjg59@srcf.ucam.org
next prev parent reply other threads:[~2009-06-08 14:35 UTC|newest] Thread overview: 199+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-06-06 22:54 [RFC][PATCH 0/2] PM: Rearrange core suspend code Rafael J. Wysocki 2009-06-06 22:55 ` [RFC][PATCH 1/2] PM: Separate suspend to RAM functionality from core Rafael J. Wysocki 2009-06-06 22:55 ` Rafael J. Wysocki 2009-06-08 6:36 ` Pavel Machek 2009-06-08 6:36 ` Pavel Machek 2009-06-06 22:56 ` [RFC][PATCH 2/2] PM/Hibernate: Rename disk.c to hibernate.c Rafael J. Wysocki 2009-06-06 22:56 ` Rafael J. Wysocki 2009-06-08 6:37 ` Pavel Machek 2009-06-08 6:37 ` Pavel Machek 2009-06-07 20:51 ` [RFC][PATCH 0/2] PM: Rearrange core suspend code Alan Stern 2009-06-07 20:51 ` [linux-pm] " Alan Stern 2009-06-07 21:46 ` Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Rafael J. Wysocki 2009-06-07 21:46 ` Run-time PM idea (was: Re: [linux-pm] " Rafael J. Wysocki 2009-06-07 22:02 ` Run-time PM idea (was: " Oliver Neukum 2009-06-07 22:02 ` Run-time PM idea (was: Re: [linux-pm] " Oliver Neukum 2009-06-07 22:02 ` Oliver Neukum 2009-06-07 22:05 ` Run-time PM idea (was: " Oliver Neukum 2009-06-07 22:05 ` [linux-pm] " Oliver Neukum 2009-06-08 11:29 ` Rafael J. Wysocki 2009-06-08 11:29 ` [linux-pm] " Rafael J. Wysocki 2009-06-08 12:04 ` Oliver Neukum 2009-06-08 18:34 ` Rafael J. Wysocki 2009-06-09 7:25 ` Oliver Neukum 2009-06-09 7:25 ` [linux-pm] " Oliver Neukum 2009-06-09 14:33 ` Alan Stern 2009-06-09 14:33 ` [linux-pm] " Alan Stern 2009-06-09 14:33 ` Alan Stern 2009-06-09 14:48 ` Oliver Neukum 2009-06-09 14:48 ` Oliver Neukum 2009-06-09 14:48 ` Oliver Neukum 2009-06-09 22:44 ` [linux-pm] " Rafael J. Wysocki 2009-06-09 22:44 ` Rafael J. Wysocki 2009-06-08 18:34 ` Rafael J. Wysocki 2009-06-08 12:04 ` Oliver Neukum 2009-06-08 20:35 ` Alan Stern 2009-06-08 20:35 ` [linux-pm] " Alan Stern 2009-06-08 20:35 ` Alan Stern 2009-06-08 21:31 ` Rafael J. Wysocki 2009-06-09 2:49 ` Alan Stern 2009-06-09 2:49 ` Alan Stern 2009-06-09 22:57 ` Rafael J. Wysocki 2009-06-10 8:29 ` [patch update] " Rafael J. Wysocki 2009-06-10 8:29 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-10 14:20 ` [patch update] " Oliver Neukum 2009-06-10 14:20 ` [patch update] Re: [linux-pm] " Oliver Neukum 2009-06-10 19:27 ` Rafael J. Wysocki 2009-06-10 21:38 ` Oliver Neukum 2009-06-10 21:38 ` Oliver Neukum 2009-06-10 22:01 ` [patch update] " Rafael J. Wysocki 2009-06-10 22:01 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-10 23:07 ` Oliver Neukum 2009-06-10 23:07 ` Oliver Neukum 2009-06-10 23:42 ` [patch update] " Alan Stern 2009-06-10 23:42 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-10 23:42 ` Alan Stern 2009-06-11 13:48 ` Rafael J. Wysocki 2009-06-11 13:57 ` [patch update] " Oliver Neukum 2009-06-11 13:57 ` [patch update] Re: [linux-pm] " Oliver Neukum 2009-06-11 14:16 ` [patch update] " Alan Stern 2009-06-11 14:16 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-11 14:16 ` Alan Stern 2009-06-11 19:38 ` [patch update] " Rafael J. Wysocki 2009-06-11 19:38 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-11 13:48 ` [patch update] " Rafael J. Wysocki 2009-06-11 13:46 ` Rafael J. Wysocki 2009-06-11 13:46 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-10 23:07 ` [patch update] " Oliver Neukum 2009-06-10 21:38 ` Oliver Neukum 2009-06-10 19:27 ` Rafael J. Wysocki 2009-06-10 21:14 ` Alan Stern 2009-06-10 21:14 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-10 21:31 ` [patch update] " Rafael J. Wysocki 2009-06-10 21:31 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-10 23:15 ` [patch update] " Oliver Neukum 2009-06-10 23:15 ` [patch update] Re: [linux-pm] " Oliver Neukum 2009-06-10 23:15 ` Oliver Neukum 2009-06-11 5:27 ` [patch update] " Magnus Damm 2009-06-11 5:27 ` [patch update] Re: [linux-pm] " Magnus Damm 2009-06-11 5:27 ` Magnus Damm 2009-06-10 23:42 ` Alan Stern 2009-06-11 14:17 ` [patch update] " Rafael J. Wysocki 2009-06-11 14:17 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-11 14:52 ` [patch update] " Alan Stern 2009-06-11 14:52 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-11 15:06 ` Oliver Neukum 2009-06-11 15:06 ` Oliver Neukum 2009-06-11 15:22 ` Alan Stern 2009-06-11 15:22 ` Alan Stern 2009-06-11 16:05 ` Oliver Neukum 2009-06-11 16:05 ` Oliver Neukum 2009-06-11 18:36 ` [patch update] " Alan Stern 2009-06-11 18:36 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-11 18:36 ` Alan Stern 2009-06-11 21:05 ` [patch update] " Oliver Neukum 2009-06-11 21:05 ` [patch update] Re: [linux-pm] " Oliver Neukum 2009-06-11 21:05 ` Oliver Neukum 2009-06-12 2:16 ` Alan Stern 2009-06-12 2:16 ` Alan Stern 2009-06-12 8:15 ` Oliver Neukum 2009-06-12 14:32 ` [patch update] " Alan Stern 2009-06-12 14:32 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-12 14:32 ` Alan Stern 2009-06-12 19:09 ` [patch update] " Rafael J. Wysocki 2009-06-12 19:09 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-12 19:48 ` Alan Stern 2009-06-12 19:56 ` [patch update] " Rafael J. Wysocki 2009-06-12 19:56 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-12 21:23 ` Alan Stern 2009-06-12 23:06 ` [patch update] " Rafael J. Wysocki 2009-06-12 23:06 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-13 18:08 ` [patch update] " Alan Stern 2009-06-13 18:08 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-13 22:04 ` [patch update] " Rafael J. Wysocki 2009-06-13 22:04 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-12 21:23 ` [patch update] " Alan Stern 2009-06-12 19:48 ` Alan Stern 2009-06-12 8:15 ` Oliver Neukum 2009-06-12 2:16 ` Alan Stern 2009-06-11 16:05 ` Oliver Neukum 2009-06-11 15:22 ` Alan Stern 2009-06-11 15:06 ` Oliver Neukum 2009-06-11 19:43 ` Rafael J. Wysocki 2009-06-11 19:43 ` [patch update] Re: [linux-pm] " Rafael J. Wysocki 2009-06-12 14:25 ` [patch update] " Alan Stern 2009-06-12 14:25 ` [patch update] Re: [linux-pm] " Alan Stern 2009-06-10 23:42 ` [patch update] " Alan Stern 2009-06-11 5:18 ` [patch update] Re: [linux-pm] " Magnus Damm 2009-06-11 5:18 ` Magnus Damm 2009-06-11 9:08 ` Oliver Neukum 2009-06-12 3:13 ` [patch update] " Magnus Damm 2009-06-12 3:13 ` [patch update] Re: [linux-pm] " Magnus Damm 2009-06-12 8:11 ` Oliver Neukum 2009-06-12 10:54 ` [patch update] " Magnus Damm 2009-06-12 10:54 ` [patch update] Re: [linux-pm] " Magnus Damm 2009-06-12 10:54 ` Magnus Damm 2009-06-12 8:11 ` [patch update] " Oliver Neukum 2009-06-11 9:08 ` Oliver Neukum 2009-06-11 5:18 ` Magnus Damm 2009-06-10 20:48 ` [linux-pm] " Alan Stern 2009-06-10 20:48 ` Alan Stern 2009-06-10 21:15 ` Rafael J. Wysocki 2009-06-10 21:15 ` [linux-pm] " Rafael J. Wysocki 2009-06-10 20:48 ` Alan Stern 2009-06-09 22:57 ` Rafael J. Wysocki 2009-06-09 2:49 ` Alan Stern 2009-06-09 7:31 ` [linux-pm] " Oliver Neukum 2009-06-09 7:31 ` Oliver Neukum 2009-06-09 23:02 ` Rafael J. Wysocki 2009-06-09 23:02 ` [linux-pm] " Rafael J. Wysocki 2009-06-09 7:31 ` Oliver Neukum 2009-06-08 21:31 ` Rafael J. Wysocki 2009-06-08 6:54 ` Ingo Molnar 2009-06-08 6:54 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 11:30 ` Rafael J. Wysocki 2009-06-08 13:05 ` Ingo Molnar 2009-06-08 13:11 ` Matthew Garrett 2009-06-08 13:22 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 13:22 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 13:32 ` Matthew Garrett 2009-06-08 13:46 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 13:46 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 13:54 ` Run-time PM idea (was: " Matthew Garrett 2009-06-08 13:54 ` Run-time PM idea (was: Re: [linux-pm] " Matthew Garrett 2009-06-08 14:24 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 14:24 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 14:35 ` Matthew Garrett [this message] 2009-06-08 14:35 ` Matthew Garrett 2009-06-08 14:44 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 14:44 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 14:51 ` Matthew Garrett 2009-06-24 15:03 ` Run-time PM idea (was: " Pavel Machek 2009-06-24 15:03 ` Run-time PM idea (was: Re: [linux-pm] " Pavel Machek 2009-06-08 14:51 ` Run-time PM idea (was: " Matthew Garrett 2009-06-19 1:50 ` Robert Hancock 2009-06-19 1:50 ` Robert Hancock 2009-06-08 13:58 ` Oliver Neukum 2009-06-08 13:58 ` Run-time PM idea (was: Re: [linux-pm] " Oliver Neukum 2009-06-08 13:58 ` Oliver Neukum 2009-06-08 13:32 ` Run-time PM idea (was: " Matthew Garrett 2009-06-08 13:39 ` Oliver Neukum 2009-06-08 13:39 ` Run-time PM idea (was: Re: [linux-pm] " Oliver Neukum 2009-06-08 13:44 ` Run-time PM idea (was: " Matthew Garrett 2009-06-08 13:44 ` Run-time PM idea (was: Re: [linux-pm] " Matthew Garrett 2009-06-08 14:21 ` Ingo Molnar 2009-06-08 14:30 ` Matthew Garrett 2009-06-08 15:06 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 15:06 ` Run-time PM idea (was: Re: [linux-pm] " Ingo Molnar 2009-06-08 15:11 ` Matthew Garrett 2009-06-08 15:11 ` Run-time PM idea (was: " Matthew Garrett 2009-06-08 16:29 ` Ray Lee 2009-06-08 16:29 ` Run-time PM idea (was: Re: [linux-pm] " Ray Lee 2009-06-08 16:29 ` Ray Lee 2009-06-08 14:30 ` Run-time PM idea (was: " Matthew Garrett 2009-06-09 22:44 ` Jiri Kosina 2009-06-09 22:44 ` Run-time PM idea (was: Re: [linux-pm] " Jiri Kosina 2009-06-08 14:21 ` Run-time PM idea (was: " Ingo Molnar 2009-06-08 13:11 ` Matthew Garrett 2009-06-08 13:05 ` Ingo Molnar 2009-06-08 11:30 ` Rafael J. Wysocki
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=20090608143513.GB16752@srcf.ucam.org \ --to=mjg59@srcf.ucam.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@lists.linux-foundation.org \ --cc=mingo@elte.hu \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.