Messages in this thread | | | Date | Thu, 10 Jul 2014 15:52:16 +0200 | From | Jens Axboe <> | Subject | Re: scsi-mq V2 |
| |
On 2014-07-10 15:50, Benjamin LaHaise wrote: > On Thu, Jul 10, 2014 at 03:48:10PM +0200, Jens Axboe wrote: >> On 2014-07-10 15:44, Benjamin LaHaise wrote: >>> On Thu, Jul 10, 2014 at 03:39:57PM +0200, Jens Axboe wrote: >>>> That's how fio always runs, it sets up the context with the exact queue >>>> depth that it needs. Do we have a good enough understanding of other aio >>>> use cases to say that this isn't the norm? I would expect it to be, it's >>>> the way that the API would most obviously be used. >>> >>> The problem with this approach is that it works very poorly with per cpu >>> reference counting's batching of references, which is pretty much a >>> requirement now that many core systems are the norm. Allocating the bare >>> minimum is not the right thing to do today. That said, the default limits >>> on the number of requests probably needs to be raised. >> >> Sorry, that's a complete cop-out. Then you handle this internally, >> allocate a bigger pool and cap the limit if you need to. Look at the >> API. You pass in the number of requests you will use. Do you expect >> anyone to double up, just in case? Will never happen. >> >> But all of this is side stepping the point that there's a real bug >> reported here. The above could potentially explain the "it's using X >> more CPU, or it's Y slower". The above is a softlock, it never completes. > > I'm not trying to cop out on this -- I'm asking for a data point to see > if changing the request limits has any effect.
Fair enough, if the question is "does it solve the regression", then it's a valid data point. Rob/Doug, for fio, you can just double the iodepth passed in in engines/libaio:fio_libaio_init() and test with that and see if it makes a difference.
-- Jens Axboe
| |