Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932256AbbFIHTb (ORCPT ); Tue, 9 Jun 2015 03:19:31 -0400 Received: from verein.lst.de ([213.95.11.211]:46262 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751344AbbFIHTX (ORCPT ); Tue, 9 Jun 2015 03:19:23 -0400 Date: Tue, 9 Jun 2015 09:19:21 +0200 From: Christoph Hellwig To: "Nicholas A. Bellinger" Cc: Christoph Hellwig , "Nicholas A. Bellinger" , target-devel , linux-scsi , linux-kernel , Hannes Reinecke , Sagi Grimberg Subject: Re: [RFC 0/2] target: Add TFO->complete_irq queue_work bypass Message-ID: <20150609071921.GA10590@lst.de> References: <1432281446-31080-1-git-send-email-nab@daterainc.com> <20150603125756.GA19696@lst.de> <1433401569.18125.112.camel@haakon3.risingtidesystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1433401569.18125.112.camel@haakon3.risingtidesystems.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1409 Lines: 30 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 types. > > This is because vhost_work_queue() is just updating vhost_dev->work_list > and immediately wake_up_process() into a different vhost_worker() > process context. For heavy small block workloads into fast IBLOCK > backends, avoiding this extra context switch should be a nice efficiency > win. How about trying to merge the two workers instead? > Perhaps tcm_loop LLD code should just be limited to RAMDISK here..? I'd prefer to not do it especially for the loopback code, as that should serve as a simple example. But before making further judgement I'd really like to see the numbers. Note that something that might help much more is getting rid of the remaining irq or bh disabling spinlocks in the target core, as that tends to introduce a lot of additional latency. Moving additional code to hardirq context is fairly diametrical to that design. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/