Message-Id: <201603210758.u2L7wiLT001242@d06av01.portsmouth.uk.ibm.com>
In-Reply-To: <1458339291-4093-1-git-send-email-bsd@redhat.com>
To: Bandan Das <bsd@redhat.com>
Cc: tj@kernel.org, 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: Mon, 21 Mar 2016 09:58:39 +0200
References: <1458339291-4093-1-git-send-email-bsd@redhat.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Content-Type: text/plain; charset="US-ASCII"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1685
Lines: 44

Hi Bandan,

> From: Bandan Das <bsd@redhat.com>
> 
> At Linuxcon last year, based on our presentation "vhost: sharing is 
better" [1],
> we had briefly discussed the idea of cgroup aware workqueues with Tejun. 
The
> following patches are a result of the discussion. They are in no way 
complete in
> that the changes are for unbounded workqueues only, but I just wanted to 
present my
> unfinished work as RFC and get some feedback.
> 
> 1/4 and 3/4 are simple cgroup changes and add a helper function.
> 2/4 is the main implementation.
> 4/4 changes vhost to use workqueues with support for cgroups.
>
> Example:
> vhost creates a worker thread when invoked for a kvm guest. Since,
> the guest is a normal process, the kernel thread servicing it should be
> attached to the vm process' cgroups.

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 
opportunity for optimization, at least for some workloads...
That said, I believe that switching vhost to use workqueues is not that 
good idea after all.
 
> Netperf:
> Two guests running netperf in parallel.
>                                  Without patches                  With 
patches
> 
> TCP_STREAM (10^6 bits/second)         975.45              978.88 
> TCP_RR (Trans/second)            20121              18820.82
> UDP_STREAM (10^6 bits/second)         1287.82                1184.5
> UDP_RR (Trans/second)            20766.72              19667.08
> Time a 4G iso download            2m 33 seconds           3m 02 seconds

--
Sincerely yours,
Mike.