RE: Let init know user wants to shutdown

RE: Let init know user wants to shutdown

[Grover, Andrew]

> From: David S. Miller [mailto:davem@redhat.com]
>  > IMHO an abstracted interface at this point is overengineering.
> 
> ACPI is the epitome of overengineering.

Hi David,

I definitely set myself up for that one. ;-) And, you're not wrong. But,
let's be clear on one thing, there are two interfaces under consideration:
1) How the kernel interacts with the platform to do power
management/configuration and 2) How the OS exposes its PM interface to ring
3.

#1 is defined by ACPI and it's too late to improve it - it's the standard. I
think it's a net improvement (by getting rid of several ugly existing
interfaces like APM, pnpbios, and MPS tables) but also realize that *we have
stepped up* to implement ACPI support, a not inconsiderable effort. You may
think this is cleaning up a mess we made ourselves but there are clear,
large, advantages that ACPI-enabled systems will have over non-ACPI ones.
Windows 2000 is a great mobile OS in large part due to ACPI.

#2 was what I was referring to with the overengineering comment. Basically,
we want to put PM policy in userspace because that's where Unix puts these
things, right? We have more functionality than other PM options, therefore
we need the most elaborate PM kernel<-->user interface. My point was that we
don't even have a functional PM policy daemon at this point, so it's a
little early to start generalizing the interface, in my opinion, but a
generalized PM interface is OK, as long as it exposes at least the level of
functionality ACPI does. A generalized interface is more work, and I see no
benefit *right now*. We'll see when someone designs one, I guess.

> An abstracted interface would allow simpler systems to avoid all of
> the bloated garbage ACPI brings with it.  Sorry, Alan hit it right on
> the head, ACPI is not much more than keeping speedstep proprietary.

This is not correct. ACPI 1.0 existed before SpeedStep was even conceived
of. The 1.0 spec contains no mention of processor performance states, or
device performance states. ACPI 2.0 does, but it provides a generic
interface for the OS to control processor performance, thus commoditizing
SpeedStep-type functionality in the future.

Clear?

Regards -- Andy

RE: Let init know user wants to shutdown

[David S. Miller]

Grover, Andrew writes:
 > A generalized interface is more work, and I see no
 > benefit *right now*. We'll see when someone designs one, I guess.

If the whole world were ACPI, yes I would not see a benefit either,
but for PPC, UltraSPARC-III etc. systems there is going to be a gain.

These systems do power management in a way that is in many ways quite
different from the models provided by ACPI.

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.

This kind of pm model with triggers and available low power states can
be used to solve problems PM was not designed to solve.  For example,
if fans begin to fail and temperature indicates we might begin to
overheat, we can reduce clock the cpus to reduce the heat before doing
something more drastic like shutting the system down.  Basically,
environment control problems can be expressed within this framework.

You get the idea.  And none of it has anything to do with ACPI, Sun's
Ultra-III platform power management scheme, or what Apple uses in the
iBook.

This is the kind of model I like because it doesn't "look" like any
particular implementation of power management, it "is" power
management.  I can plug any hardware PM scheme into that.

Later,
David S. Miller
davem@redhat.com

Re: Let init know user wants to shutdown [linux-power] [linux-pm-devel] [linux-kernel-mailing-list] [some-other-list]

[David Woodhouse]

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

Re: Let init know user wants to shutdown [linux-power] [linux-pm-devel] [linux-kernel-mailing-list] [some-other-list]

[Pavel Machek]

Hi!

> > 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. 

I believe that at least thermal managment should be done in
kernelspace. You do not want to overheat your cpu because you
accidentally killed powerd, right?
								Pavel
-- 
The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+