[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110202102521.GA24115@htj.dyndns.org>
Date: Wed, 2 Feb 2011 11:25:21 +0100
From: Tejun Heo <tj@...nel.org>
To: Mike Christie <michaelc@...wisc.edu>
Cc: linux-kernel@...r.kernel.org,
Jayamohan Kallickal <jayamohank@...verengines.com>,
Andrew Vasquez <andrew.vasquez@...gic.com>,
"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
linux-scsi@...r.kernel.org
Subject: Re: [PATCH 16/32] scsi/be2iscsi,qla2xxx: convert to
alloc_workqueue()
Hello,
On Tue, Feb 01, 2011 at 05:45:13PM -0600, Mike Christie wrote:
> I think these are used in the main IO path, so would you also want
> WQ_HIGHPRI | WQ_CPU_INTENSIVE to be set?
Maybe HIGHPRI but definitely not CPU_INTENSIVE, but even HIGHPRI isn't
usually necessary. The queue of pending works tend to be short and
consumed pretty fast.
> I think qla2xxx was using this in a path they expected to have high
> throughput/low latency, and from the interrupt handler they would
> try to queue the work on the same cpu the isr was answered on. With
> the new workqueue code could you possibly get queued onto a
> workqueue that is doing other work for other drivers?
There are no separate workqueues. There's one per cpu which is used
by all workqueue users. HIGHPRI boosts the queueing order in that
queue.
> Should qla2xxx be using the blkiopoll framework instead of a
> workqueue or will workqueues still provide the same performance when
> setting WQ_HIGHPRI | WQ_CPU_INTENSIVE?
CPU_INTENSIVE isn't applicable at all unless you want to run crypto or
zlib from the driver.
blk_iopoll runs off softirq and will always have lower latency than
workqueue which requires scheduling, so it depends on the
requirements. I guess the best thing would be playing with things a
bit and make decisions on test results. It shouldn't be too difficult
to switch among them.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists