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
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
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
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
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
5 matches
Mail list logo