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. -ben > -- > Jens Axboe -- "Thought is the essence of where you are now." -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
