linux-kernel - Re: [linux-pm] Power management for SCSI

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]

Date:	Tue, 19 Aug 2008 15:33:14 +0200
From:	Oliver Neukum <oneukum@...e.de>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Pavel Machek <pavel@...e.cz>, linux-pm@...ts.linux-foundation.org,
	James.Bottomley@...senpartnership.com,
	"Linux-pm mailing list" <linux-pm@...ts.osdl.org>,
	kernel list <linux-kernel@...r.kernel.org>, teheo@...ell.com
Subject: Re: [linux-pm] Power management for SCSI

Am Freitag 15 August 2008 17:25:13 schrieb Alan Stern:
> On Fri, 15 Aug 2008, Oliver Neukum wrote:
> 
> > Am Freitag 15 August 2008 00:25:28 schrieb Alan Stern:

Hi,

> > Yes, that means under some circumstances you cannot suspend the
> > member closest to the CPU, but under others you can. In a tree this question
> > is very simply answered, on a bus you will actually need to compute whether
> > you need the connection to the bus.

> More to the point is whether you should ever suspend any of these 
> devices if there can be multiple initiators.  But that's a separate 
> question.

But one that needs to be addressed.

> > It is true that you won't need the bus if all other members on the bus have
> > been suspended, but that's not very good because physically spinning
> > down and up a disk is a very expensive operation, while suspending a host
> > adapter can be trivial.
> 
> What is your point?  You seem to be saying that it would be nice to
> suspend a host adapter at times when some of the SCSI targets beneath
> it are not suspended.  I agree, but how would you determine whether
> such a thing was safe?

I suggest by talking to the HLDs.

It seems to me that abstractly talking there are three criteria for suspension

- the cpu needs to talk to the device now
- the device may need to talk to the CPU at unpredictable times
- suspending has side effects

Suspension in USB has always side effects. That's not true for other
subsystems. It seems to me that for the general case we need to divorce
the notion of a child being suspended itself from a child agreeing to its
parent being suspended.

	Regards
		Oliver


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