linux-kernel - Runtime PM and the block layer

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 23 Aug 2010 15:17:40 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jens Axboe <axboe@...nel.dk>
cc:	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Runtime PM and the block layer

Jens:

I want to implement runtime power management for the SCSI sd driver.  
The idea is that the device should automatically be suspended after a
certain amount of time spent idle.

The basic outline is simple enough.  If the device is in low power when
a request arrives, delay handling the request until the device can be
brought back to high power.  When a request completes and the request
queue is empty, schedule a runtime-suspend for the appropriate time in
the future.

The difficulty is that I don't know the right way these things should
interact with the request-queue management.  A request can be deferred
by making the prep_req_fn return BLKPREP_DEFER, right?  But then what
happens to the request and to the queue?  How does the runtime-resume
routine tell the block layer that the deferred request should be
restarted?

How does this all relate to the queue being stopped or plugged?

Another thing: The runtime-resume routine needs to send its own
commands to the device (to spin up a drive, for example).  These
commands must be sent before anything on the request queue, and they
must be handled right away even though the normal requests on the queue
are still deferred.

What's the right way to do all this?

Thanks,

Alan Stern

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