James Carlson wrote:
> Terry Whatley writes:
>
>> The IO framework and driver stack will be enhanced to provide generic
>> support of modern disks' power management capabilities. The new
>> features include support of SPC-4/SBC-3 compliant disk power conditions.
>> The SATA framework will be enhanced to provide comparable software
>> translation between ATA power conditions and SBC-3 power conditions.
>>
>
> Where's the rest of this project? I would expect that, in order to
> finish this project, there's some work necessary to make the power
> management subsystem consume this data. That doesn't appear to be a
> part of this project, though.
>
>
No, the existing power management subsystem is not intended to consume
this information.
The existing pm framework will eventually be superseded* by a
resource manager-based architecture where power management control
of different devices will be taken by "resource managers" which have
specific knowledge of the pm properties and usage of the devices.
Some likely examples are the Solaris power aware dispatcher (CPU),
file systems (disks), an advanced VM subsystem (memory), etc.
In the cases where the autopm system already expects to manage the devices
(cpu, disk), control would be taken away from the existing pm framework
(and later, possibly, returned). (Autopm is already accustomed to
having control
taken away, as X takes control of the frame buffer).
* Will still exist, and will, if autopm is enabled, still control any
devices
that have not been claimed by a resource manager.
But that is not this case.
> Are the folks responsible for supporting autopm and the rest of the
> power management subsystem involved with this project?
>
>
Yes, Randy Fishel has been involved in design discussion and code review
(and the x86power-iteam alias has been copied on code review requests).
> If not, are they aware of what this project is planning to deliver,
> and do they agree that the information will be usable to make power
> management decisions?
>
>
The information being delivered is not intended for use by the existing
power management (autopm) framework. The eventual plan is to
supplement that functionality (which is based on a backward-looking
idleness threshold) with the resource manager-based system mentioned above.
But that is not this case.
The only intersection between this specific case and the existing pm
framework is the pm_trans_check(9F) function, which remains backwards
compatible with the existing code while extending identical functionality
to a class of devices (non-SCSI disks) not currently served, since this case
would make the relevant information available.
> If so, is there a future project ("autopm disk enhancements") that is
> dependent on this one?
>
>
No
The directly dependent case on this one is likely to be approximately
"kernel interfaces for resource power managers" which might also be
used by a "power aware dispatcher as a cpu resource manager" case, and
likely a "file system as a pm resource manager" case, etc.
We intended to present all levels together, but have been asked to produce
these low level interfaces in the mean time for intermediate use while
we finish the design documentation necessary to present the "next level
up" case. We are confident that the interfaces exposed here will not
be changed by the next level case, as they are specific to the description
of the power states supported by modern disk drives, which will be needed
whatever the upper level interfaces are.
> Help us to connect the dots from the set of low-level driver
> properties described here to the higher-level goal of providing better
> disk management.
>
Interfaces in the current pm framework already exist that could be used to
provide better disk management given the information this current
case provides. There are /dev/pm ioctls (see PSARC/1999/384) that
could be used by an application (or kernel subsystem, via layered ioctls)
to manage the power state of any given device(s). This current
case provides only the information that such a controlling entity would need
to know about the pm features of modern disks.
This case does not require changes in the autopm framework except
minor changes in pm_trans_check(9F), which is just an enhancement
to improve current functionality if additional information
(cycle count info from non-scsi devices) is available, and the addition
of a hook for later use (the "dip" argument).
thanks,
sarito
