From: David Woodhouse <dwmw2@infradead.org>
To: "David S. Miller" <davem@redhat.com>
Cc: "Grover, Andrew" <andrew.grover@intel.com>,
"'John Fremlin'" <chief@bandits.org>,
"'Simon Richter'"
<Simon.Richter@phobos.fachschaften.tu-muenchen.de>,
"Acpi-PM (E-mail)"
<linux-power@phobos.fachschaften.tu-muenchen.de>,
"'Pavel Machek'" <pavel@suse.cz>,
Andreas Ferber <aferber@techfak.uni-bielefeld.de>,
linux-kernel@vger.kernel.org
Subject: Re: Let init know user wants to shutdown [linux-power] [linux-pm-devel] [linux-kernel-mailing-list] [some-other-list]
Date: Fri, 27 Apr 2001 10:03:12 +0100 [thread overview]
Message-ID: <17244.988362192@redhat.com> (raw)
In-Reply-To: <15080.40123.543633.854889@pizda.ninka.net>
In-Reply-To: <15080.40123.543633.854889@pizda.ninka.net> <4148FEAAD879D311AC5700A0C969E89006CDDD9F@orsmsx35.jf.intel.com>
davem@redhat.com said:
> You can break the whole power management problem down to "here are the
> levels of low-power provided by the hardware, here are the idleness
> triggers that may be monitored". That's it, nothing more.
> This is powerful enough to do all the things you could want a pm layer
> to do:
>
> 1) CPU's have been in their idle threads for X percent of
> of the past measurement quantum, half clock the processors.
>
> 2) The user has hit the "sleep" trigger, spin down the disks,
> reduce clock the cpus, bus, PCI controller and PCI devices.
Often the 'sleep trigger' is an _absence_ of activity rather than anything
explicit like a button being pressed. You need inactivity timers, and events
which _reset_ those timers, on triggers like keyboard/touchscreen/serial
input, etc.
It's arguable that you can do that in userspace. Possibly - I'm not 100%
convinced of that. If you have many events which can reset many different
timers, the amount of traffic between kernel and user space just to reset
those timers may be quite high.
If an inactivity timer is implemented in userspace, with serial input being
one of the events that resets it, you're going to get a lot of wakeup/reset
events if you do a large download over that port.
It's possible that we could optimise that somehow, so we can avoid having
to implement PM timers in kernelspace. I'm not sure. Perhaps the wakeup
events could be on a separate queue, with no duplicates permitted, and the
PM daemon could poll that queue only when it's about to shoot one of its
timers.
For maximum efficiency, when receiving an event in sleep mode which isn't
supposed to wake the system, we should drop the event and go back to sleep
as quickly as possible. If you have to run userspace processes to make that
decision, it's not going to be particularly fast.
It may be sensible to have a simple policy engine in the kernel which
implement a policy provided by userspace. Some kind of simple state machine.
--
dwmw2
next prev parent reply other threads:[~2001-04-27 9:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-18 22:52 Let init know user wants to shutdown Grover, Andrew
2001-04-26 22:10 ` David S. Miller
2001-04-27 9:03 ` David Woodhouse [this message]
2001-04-27 10:58 ` Let init know user wants to shutdown [linux-power] [linux-pm-devel] [linux-kernel-mailing-list] [some-other-list] Pavel Machek
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=17244.988362192@redhat.com \
--to=dwmw2@infradead.org \
--cc=Simon.Richter@phobos.fachschaften.tu-muenchen.de \
--cc=aferber@techfak.uni-bielefeld.de \
--cc=andrew.grover@intel.com \
--cc=chief@bandits.org \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-power@phobos.fachschaften.tu-muenchen.de \
--cc=pavel@suse.cz \
/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 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.