[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161222171224.GA26830@vader>
Date: Thu, 22 Dec 2016 09:12:24 -0800
From: Omar Sandoval <osandov@...ndov.com>
To: Bart Van Assche <Bart.VanAssche@...disk.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"osandov@...com" <osandov@...com>, "axboe@...com" <axboe@...com>,
"axboe@...nel.dk" <axboe@...nel.dk>,
"paolo.valente@...aro.org" <paolo.valente@...aro.org>
Subject: Re: [PATCHSET v4] blk-mq-scheduling framework
On Thu, Dec 22, 2016 at 04:57:36PM +0000, Bart Van Assche wrote:
> On Thu, 2016-12-22 at 08:52 -0800, Omar Sandoval wrote:
> > This approach occurred to us, but we couldn't figure out a way to make
> > blk_mq_tag_to_rq() work with it. From skimming over the patches, I
> > didn't see a solution to that problem.
>
> Hello Omar,
>
> Can you clarify your comment? Since my patches initialize both tags->rqs[]
> and sched_tags->rqs[] the function blk_mq_tag_to_rq() should still work.
>
> Bart.
Sorry, you're right, it does work, but tags->rqs[] ends up being the
extra lookup table. I suspect that the runtime overhead of keeping that
up to date could be worse than copying the rq fields if you have lots of
CPUs but only one hardware queue.
Powered by blists - more mailing lists