Message-Id: <201603310617.u2V6HIkt008006@d06av12.portsmouth.uk.ibm.com>
In-Reply-To: <20160330170419.GG7822@mtj.duckdns.org>
To: Tejun Heo <tj@kernel.org>
Cc: Bandan Das <bsd@redhat.com>, linux-kernel@vger.kernel.org,
        kvm@vger.kernel.org, mst@redhat.com, jiangshanlai@gmail.com
Subject: Re: [RFC PATCH 0/4] cgroup aware workqueues
From: "Michael Rapoport" <RAPOPORT@il.ibm.com>
Date: Thu, 31 Mar 2016 08:17:13 +0200
References: <1458339291-4093-1-git-send-email-bsd@redhat.com>
 <201603210758.u2L7wiY9003907@d06av07.portsmouth.uk.ibm.com>
 <20160330170419.GG7822@mtj.duckdns.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Content-Type: text/plain; charset="US-ASCII"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1184
Lines: 40

Hello,

> Tejun Heo <htejun@gmail.com> wrote on 03/30/2016 08:04:19 PM:
> 
> Hello,
> 
> On Mon, Mar 21, 2016 at 09:58:39AM +0200, Michael Rapoport wrote:
> > I did some performance evaluation of different threading models in 
vhost, 
> > and in most tests replacing vhost kthread's with workqueues degrades 
the 
> > performance. Moreover, having thread management inside the vhost 
provides 
> 
> There really shouldn't be any difference when using unbound
> workqueues.  workqueue becomes a convenience thing which manages
> worker pools and there shouldn't be any difference between workqueue
> workers and kthreads in terms of behavior.

I agree that there really shouldn't be any performance difference, but the 
tests I've run show otherwise. I have no idea why and I hadn't time yet to 
investigate it.
 
> > opportunity for optimization, at least for some workloads...
> 
> What sort of optimizations are we talking about?

Well, if we take Evlis (1) as for the theoretical base, there could be 
benefit of doing I/O scheduling inside the vhost.

[1] https://www.usenix.org/system/files/conference/atc13/atc13-harel.pdf

> Thanks.
> 
> -- 
> tejun

--
Sincerely yours,
Mike.