linux-kernel - Re: [patch 2/4] Expose Power Management Policy option to users

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070731125849.501443c1.kristen.c.accardi@intel.com>
Date:	Tue, 31 Jul 2007 12:58:49 -0700
From:	Kristen Carlson Accardi <kristen.c.accardi@...el.com>
To:	Tejun Heo <htejun@...il.com>
Cc:	Jeff Garzik <jeff@...zik.org>, James.Bottomley@...eleye.com,
	linux-scsi@...r.kernel.org, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	edwintorok@...il.com, axboe@...nel.dk
Subject: Re: [patch 2/4] Expose Power Management Policy option to users

On Wed, 01 Aug 2007 03:02:55 +0900
Tejun Heo <htejun@...il.com> wrote:

> Kristen Carlson Accardi wrote:
> > I think what you are saying is that you'd like a way to use your HIPM
> > and DIPM without ALPM on the AHCI driver.  Fine - it's really easy
> > to add these levels later - if they don't make sense at the sysfs interface
> > we can add module params to specify the definition of "min_power" as 
> > being performed via HIPM and DIPM instead of ALPM - although as of yet we
> > have no evidence what so ever that this method actually adds value over
> > ALPM.
> 
> I don't really care whose PS implementation goes in.  Believe me.  I try
> to stay away from that.  I don't even like my previous implementation.
> 
> ALPM has unnecessary performance penalty && is not applicable to
> non-ahci controller.  Have you tested ALPM on non-intel ahcis?  There
> are a lot out there these days.

I have not personally, however there has been a lot of testing of this
hardware feature both on other OS and for this particular implementation
by the powertop community, which is composed of community members running
all sorts of hardware.  So far I've not received any bug reports
wrt non-intel AHCI.  As I mentioned several times, the default for ALPM
is to be off anyway.

> 
> I don't think the interface you're suggesting is a good one.  Do you?

I think if it's applicable to SCSI at all it is fine.  If it is not, then
I think we need to make do with the interface we are given.  I do not think
we should hold up a feature for libata sysfs integration.

> 
> >> Also, I generally don't think AHCI ALPM is a good idea.  It doesn't have
> >> 'cool down' period before entering PS state which unnecessarily hampers
> >> performance and might increase chance of device malfunction.
> > 
> > "might increase"?  How about some actual examples of where you've shown
> > this to be a problem?
> 
> I wouldn't have used "might" if I had actual examples.  Well, feel free
> to disregard anything following the "might".  I just feel uneasy about
> jumping back and forth between PS and active states between consecutive
> commands.

I want us to be careful about spreading a lot of unease without data to
back it up.

> 
> > I can assert that I think ALPM is a good idea,
> > because I've never had a report of it causing problems.  Windows has 
> > been using this feature for a very long time - and you have to admit that
> > they have a pretty large market share.  Nobody is complaining about ALPM
> > increasing device malfunction, so unless you have proof it seems insane
> > to nak due to this. 
> 
> Is ALPM enabled by default?  How do they deal with the performance
> degradation?

I believe so, but I'm obviously not privvy to their implementation details.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/