linux-kernel - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Pine.LNX.4.44L0.1008241030340.1652-100000@iolanthe.rowland.org>
Date:	Tue, 24 Aug 2010 10:42:25 -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: Re: Runtime PM and the block layer

On Tue, 24 Aug 2010, Jens Axboe wrote:

> > Hmm.  That doesn't sound quite like what I need.  Ideally the request
> > would go back to the head of the queue and stay there until the driver
> > tells the block layer to let it through (when the device is ready to 
> > accept it).
> 
> It depends on where you want to handle it. If you want the driver to
> reject it, then we don't have to change the block layer bits a lot. We
> could add a DEFER_AND_STOP or something, which would never retry and it
> would stop the queue. If the driver passed that back, then it would be
> responsible for starting the queue at some point in the future.
> 
> >>> How does this all relate to the queue being stopped or plugged?
> >>
> >> A stopped queue is usually the driver telling the block layer to bugger
> >> off for a while, and the driver will tell us when it's ok to resume
> >> operations.
> > 
> > Yes, that sounds more like it.  Put the request back on the queue 
> > and stop the queue.  If the prep fn calls blk_stop_queue() and then 
> > returns BLKPREP_DEFER, will that do it?
> 
> I think it will be a lot cleaner to add specific support for this, as
> per the DEFER_AND_STOP above.

Okay, good.  I'll try to implement that and see how it goes.

> Sounds like all you need is a way to return BLKPREP_DEFER_AND_STOP and
> have the block layer stop the queue for you. When you need to restart,
> you would insert a special request at the head of the queue and call
> blk_start_queue() to get things going again.

Yes.

Suppose the driver needs to send two of these special requests before
going back to normal operation.  Won't restarting the queue for the
first special request also cause the following regular request to be
passed to the driver before the second special request can be inserted?  
Of course, the driver could cope with this simply by returning another
BLKPREP_DEFER_AND_STOP.

> The only missing bit would then be the idle detection. That would need
> to be in the block layer itself, and the scheme I described should be
> fine for that still.

Are you sure it needs to be in the block layer?  Is there no way for 
the driver's completion handler to tell whether the queue is now empty?  
Certainly it already has enough information to know whether the device 
is still busy processing another request.  When the device is no longer 
busy and the queue is empty, that's when the idle timer should be 
started or restarted.

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/