lkml.org 
[lkml]   [2014]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: scsi-mq V2
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."


\
 
 \ /
  Last update: 2014-07-10 16:41    [W:0.188 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site