Messages in this thread | | | Date | Mon, 10 Dec 2007 13:16:27 +0100 | From | Jens Axboe <> | Subject | Re: [RFC] [PATCH] A clean aEvgeniy pproach to writeout throttling |
| |
On Mon, Dec 10 2007, Daniel Phillips wrote: > On Monday 10 December 2007 03:41, Jens Axboe wrote: > > On Mon, Dec 10 2007, Daniel Phillips wrote: > > > + if (q && q->metric && !bio->bi_queue) { > > > > > > This prevents any reference to bi_bdev after the intial call to > > > generic_make_request. Thanks to Evgeniy for pointing out the need > > > for this measure on the last go round. > > > > Which saves the initial target, for ease of accounting at end io time > > - that's not the point. What happens when ->make_request_fn() changes > > bio->bi_bdev and returns 1, causing another iteration of the > > __generic_make_request() loop? 'q' is no longer the valid target, > > bdev_get_queue(bio->bi_bdev) is. > > What happens on the second iteration of a recursive submission loop is > exactly nothing, as is right and proper. The throttling has already > been done, and all the state necessary to perform the unthrottle was > recorded in the bio. Everything seems to be in order there, and the > algorithm does indeed perform its function as designed, though to be > sure we have not tested it on -mm branch, only on mainline.
OK, let me get the neon out then. This has nothing to do with throttling, I thought I made it clear that I get why you store the origin queue in ->bi_queue. I'm concerned with the workings of redirecting a bio. Previously we looked up the queue associated with bio->bi_bdev inside the loop in __generic_make_request(), as is REQUIRED to correctly locate a DIFFERENT queue if bio->bi_bdev has been changed to point somewhere else.
Clear?
-- Jens Axboe
| |