Re: [RFC 0/2] target: Add TFO->complete_irq queue_work bypass

2015-06-10 Thread Nicholas A. Bellinger
On Tue, 2015-06-09 at 09:19 +0200, Christoph Hellwig wrote: > On Thu, Jun 04, 2015 at 12:06:09AM -0700, Nicholas A. Bellinger wrote: > > So I've been using tcm_loop + RAMDISK backends for prototyping, but this > > patch is intended for vhost-scsi so it can avoid the unnecessary > > queue_work() con

Re: [RFC 0/2] target: Add TFO->complete_irq queue_work bypass

2015-06-09 Thread Christoph Hellwig
On Thu, Jun 04, 2015 at 12:06:09AM -0700, Nicholas A. Bellinger wrote: > So I've been using tcm_loop + RAMDISK backends for prototyping, but this > patch is intended for vhost-scsi so it can avoid the unnecessary > queue_work() context switch within target_complete_cmd() for all backend > driver ty

Re: [RFC 0/2] target: Add TFO->complete_irq queue_work bypass

2015-06-04 Thread Sagi Grimberg
On 6/4/2015 10:06 AM, Nicholas A. Bellinger wrote: On Wed, 2015-06-03 at 14:57 +0200, Christoph Hellwig wrote: This makes lockdep very unhappy, rightly so. If you execute one end_io function inside another you basіcally nest every possible lock taken in the I/O completion path. Also adding mor

Re: [RFC 0/2] target: Add TFO->complete_irq queue_work bypass

2015-06-04 Thread Nicholas A. Bellinger
On Wed, 2015-06-03 at 14:57 +0200, Christoph Hellwig wrote: > This makes lockdep very unhappy, rightly so. If you execute > one end_io function inside another you basіcally nest every possible > lock taken in the I/O completion path. Also adding more work > to the hardirq path generally isn't a s

Re: [RFC 0/2] target: Add TFO->complete_irq queue_work bypass

2015-06-03 Thread Christoph Hellwig
This makes lockdep very unhappy, rightly so. If you execute one end_io function inside another you basіcally nest every possible lock taken in the I/O completion path. Also adding more work to the hardirq path generally isn't a smart idea. Can you explain what issues you were seeing and how much