I agree with you that this could be useful.   But we don't want to keep this
particular interface or this implementation moving forward; none
of our current boxes support it.

Just glancing through the Server spec I don't see any reference to this
type of feature; there's a real focus on idle power. When the server spec is
finalized and the requirements are derived from that, then the call can
be made as what features are necessary for server power management.

Thanks
Margot


On 04/20/10 06:03 PM, Vincent R Wang wrote:
This feature seems to be very useful for x86. IMO I agree with Randy that this looks like a bug that can be fixed.

Consider the fact that this property has existed for some time, it might be a better idea to keep a backward-compatible user interface, even if a more advanced feature is to be implemented. It'll be a good thing for the end users.

Vincent

Randy Fishel wrote:
On Tue, 20 Apr 2010, Margot Miller wrote:

This current implementation and usage model isn't what we need moving
forward.
If we decide in the future that autoshutdown is valid and
desirable we can design a better implementation and a better user interface
then.  The Energy Star for Server V2 will probably dictate a lot of the
features for the servers that need to be implemented in the future.

That the current implementation is is poor, is a reason to fix it, not to deprecate it. That there is the possibility that a new E* spec might specify a similar or improved feature makes this case possibly hasty, and will be questioned by PSARC


Removing the property removes the ability of Solaris to configure and use this feature (to some extent, this creates dead code with a dead feature). So here, if the proposal is to remove the property, then the proposal should also be to remove the feature, and it should describe why this feature is no longer desired. That's all that is being asked.

But, even hinting that we might need the feature in the future, but we want to remove the control to use it (or even the entire feature), is distasteful to me, and may well be to PSARC.

This fast track is to deprecate Auto-Shutdown for Solaris.next. Or are you talking about deprecating MOU??

We (the project team OR Oracle) cannot deprecate the MOU, it is a standard that the EPA provides. All we can do is to provide or not provide the features that allow machines running Solaris to be in compliance with it.


That aside, this feature was originally implemented in support of MOU3. The feature is still part of MOU5 compliance. Somewhere, there is a PSARC case that describes the original need for the feature. That original case should be referenced in this case, and it should describe why we that justification is no longer valid. And (IMHO) should also include answers to the questions I stated below for completeness (especially since there isn't a larger picture that describes what features we *should* be supporting).


  Cheers!

    ---- Randy

Thanks
Margot


On 04/20/10 14:54, Randy Fishel wrote:
  The question(s) I don't see answered or addressed:

    Is autoshutdown a desired feature for x86 desktops/laptops?

    Is autoshutdown a desired feature for sparc/x86 servers?

  Or possibly addressed in a different way:

    Why is it not a bug that autoshutdown doesn't work on x86?

As specified in the case, autoshutdown is part of the MOU requirements (including the current MOU5), removing this property removes the ability of Solaris to configure this feature. And if the feature is not desired in
Solaris, the case should go the distance and deprecate the feature.


  Also, have we also verified that PM_IDLETIME isn't needed anymore?
Currently, the *only* algorithm used by Solaris to transition to lower power states (including suspend via autoS3) is via idleness. So will PM_IDLETIME
also be needed for auto-suspend?

  Cheers!

    ---- Randy


On Tue, 20 Apr 2010, Margot Miller wrote:

Hi All,

This is a draft fast track proposal.

Please comment if you see any issues or need clarifications
on anything.

Thanks
Margot


Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All
rights reserved.
1. Introduction
   1.1. Project/Component Working Name:

    Auto-Shutdown power managment property deprecation

   1.2. Name of Document Author/Supplier:

    Author:  Margot Hackett Miller

   1.3  Date of This Document:

   20 April, 2010

4. Technical Description
1.0 Introduction

1.1 Project/Component Working Name:

   Auto-Shutdown power management property deprecation

1.2 Purpose

This project seeks to deprecate two Sparc workstation only property
from
power.conf as we move from power.conf to SMF.

1.3 Name of Document Author/Supplier:

   Margot Hackett Miller  [email protected]

1.4 Email Aliases:

   1.4.1 Responsible Manager:   [email protected]
   1.4.2 Responsible Engineer:  [email protected]
   1.4.3 Interest List:

2.0 Description

We are in process of moving properties from power.conf to SMF. As we do
so,
we would like to remove properties that are not longer needed or that the
hardware no longer supports.

One such property is autoshutdown and the related property idleness.

Looking at previous ARC cases, there have been quite a few ARC
cases where power management driver ioctls and power.conf properties
have been removed.


3.0 Delivery

Announcement of the deprecation would be in a Solaris 10 update
release with the actual removal of the two properties in Solaris.next.

Deprecation announcement would entail updating the man page for
power.conf and inserting a comment in power.conf stating this
property will be removed in a future Solaris release.

Deprecation of the property would be in a patch release with removal
of the feature in a minor release.

4.0 Technical Description

The two properties in question are Auto-Shutdown and idleness. These
are currently edited by the user in power.conf and then written to the
kernel
by executing pmconfig.

# Auto-Shutdown     Idle(min)    Start/Finish(hh:mm)    Behavior
autoshutdown        30          9:00 9:00              noshutdown
                                                       shutdown
                                                      autowakeup
                                                      default
                                                      unconfigured

idleness    ttychars
                 loadaverage
                 diskreads
                 nfsreqs
                  idlecheck  (name of a program of run)

There is also a PM_IDLETIME environment variable that would no longer be
needed.

The idleness property is related to the autoshutdown property to determine
idleness of system and triggers shutdown behavior.

This Auto-Shutdown/idleness feature was implemented only on SPARC
workstations for MOU3 compliance and was never implemented on any x86
boxes. Furthermore, there doesn't seem to be any plans for further SPARC
workstations or the implementation of the latest MOU5 compliance spec
on any Sun workstation. Additionally, this feature is not supported on
any
SPARC Sun4v servers.

It looks like all Sparc workstations have EOL'ed.  According to
PSARC/2009/572, all of them have been EOF'ed in OpenSolaris
except for SunUltra25 and SunUltra45.  These boxes were FCS'ed
in early 2006.


4.2 Interface Classification

    The project exports the following interfaces:

   Auto-Shutdown           power.conf property        idleness
power.conf property
PM_IDLETIME             environment variable

Current classification of these properties is Evolving, according to the power.conf man page. Still looking for the ARC case that exported them.
5.0 References

   1. Other Related ARC Cases:



6. Resources and Schedule
   6.4. Steering Committee requested information
      6.4.1. Consolidation C-team Name:
       ON
   6.5. ARC review type: FastTrack
   6.6. ARC Exposure: open

_______________________________________________
opensolaris-arc mailing list
[email protected]

_______________________________________________
pm-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pm-discuss

_______________________________________________
pm-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pm-discuss


_______________________________________________
pm-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pm-discuss

Reply via email to