Re: Doing end_that_request_last first and vice versa
Jens Axboe (axboe@image.dk)
Tue, 9 Nov 1999 18:50:48 +0100
On Tue, Nov 09 1999, Malcolm Beattie wrote:
> In a block device driver's request function, there are now two
> functions that one is supposed to call when a request has been
> completed: end_that_request_first and end_that_request_last. The former
> does the appropriate stuff to mark the buffer_head up to date, end I/O
> on it (or adjust the request on error). The latter frees up the request
> slot.
>
> I'm writing a block device driver where I'd like to take all the
> requests out of the queue and record the relevant buffer_head pointers
> elsewhere. I want to end I/O on the buffer_heads asynchronously later
> (potentially much later). In other words, I'd like to call
> end_that_request_last first (after recording the READ/WRITE commands
> and buffer_head pointers) and do the equivalent of
> end_that_request_first last, much later. Is this a valid thing to do?
> I'm fairly sure it will work but is it the Right Way (TM) to code it
> or do I risk it breaking when the buffer_heads get even closer to
> being just I/O tags? Also, is emptying the request queue a reasonable
> thing to do (since I don't want the system to run out of global
> request slots and this block device may be very, very slow)?
If you are worried about running out of requests, you can always
have your driver declare its own request table. This is what I'm
doing for the CD/DVD-R/W packet writing, since I have to generate
several new requests every time I get a new write. Stephen
Tweedie suggested doing it this way.
You might end up having to do a lot of the end_request
functionality manually though. Have you thought about
clustered requests? end_that_request_first handles
these for you too. If you do decide to call _last
first, make sure you transfer the request semaphore
to your new request.
--
* Jens Axboe <axboe@image.dk>
* Linux CD-ROM Maintainer
* http://www.kernel.dk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/