David Dillow, on 08/09/2010 06:49 PM wrote:
On Sun, 2010-08-08 at 20:19 +0200, Bart Van Assche wrote:
On Sat, Aug 7, 2010 at 6:32 PM, Roland Dreier<[email protected]> wrote:
Not sure that I follow the problem you're worried about. A given
tasklet can only be running on one CPU at any one time -- if an
interrupt occurs and reschedules the tasklet then it just runs again
when it exits.
Also I'm not sure I understand why this is special for IB hardware --
standard practice is for interrupt handlers to clear the interrupt
source and reenable interrupts, so I don't see why the same thing you
describe can't happen with any interrupt-generating device that defers
work to a tasklet.
One of the applications I have been looking at is adding blk-iopoll
support in ib_srp and to make it possible to enable and disable
blk-iopoll at runtime via sysfs. A naive implementation could look
e.g. as follows:
I'm not sure it makes sense to enable/disable this at runtime -- we
don't do it for NAPI, why do it for block devices? I'm not even sure I'd
want to see a config option for it in kbuild -- that was done during the
transition to NAPI and it lingered forever for some drivers. I'd rather
we got it correct, and not give people yet another knob to figure out.
I can certainly see a use case for testing the patch's performance,
though.
For the testing it can be done as a local to the corresponding file #ifdef.
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
