Hello, On Thu, Apr 09, 2020 at 10:38:57AM +0800, Ming Lei wrote: > On Wed, Apr 08, 2020 at 10:11:19PM -0400, Tejun Heo wrote: > > On Thu, Apr 09, 2020 at 09:44:06AM +0800, Ming Lei wrote: > > > Almost all __blk_mq_end_request() follow blk_update_request(), so the > > > completed bytes can be passed to __blk_mq_end_request(), then we can > > > avoid to introduce this field. > > > > But on some drivers blk_update_request() may be called multiple times before > > __blk_mq_end_request() is called and what's needed here is the total number of > > bytes in the whole request, not just in the final completion. > > OK. > > Another choice might be to record request bytes in rq's payload > when calling .queue_rq() only for these drivers. There sure are multiple ways to skin a cat. > > > Also there is just 20 callers of __blk_mq_end_request(), looks this kind > > > of change shouldn't be too big. > > > > This would work iff we get rid of partial completions and if we get rid of > > partial completions, we might as well stop exposing blk_update_request() and > > __blk_mq_end_request(). > > Indeed, we can store the completed bytes in request payload, so looks killing > partial completion shouldn't be too hard. There's a reason why we've had partial completions. On slower IO devices, like floppy, partial completions actually are advantageous. I'm not arguing this still holds up as a valid justification but getting rid of partial completions isn't just a decision about plumbing details either. Thanks. -- tejun
