All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bandan Das <bsd@redhat.com>
To: "Michael Rapoport" <RAPOPORT@il.ibm.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
Date: Mon, 21 Mar 2016 13:43:41 -0400	[thread overview]
Message-ID: <jpg1t73d8vm.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <201603210758.u2L7wiXA028101@d06av09.portsmouth.uk.ibm.com> (Michael Rapoport's message of "Mon, 21 Mar 2016 09:58:39 +0200")

"Michael Rapoport" <RAPOPORT@il.ibm.com> writes:

> 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

Workqueues us kthread_create internally and if calling one over the
other impacts performace, I think we should investigate that. Which
patches did you use ? Note that an earlier version of workqueue patches
that I posted used per-cpu workqueues.

> performance. Moreover, having thread management inside the vhost provides

What exactly is the advantage doing our own thread management ? Do you have
any examples ? (Besides for doing our own scheduling like in the original Elvis
paper which I don't think is gonna happen). Also, note here that there is
a possibility to affect how our work gets executed by using optional switches to
alloc_workqueue() so all is not lost.

> 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.
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-03-21 17:43 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-18 22:14 [RFC PATCH 0/4] cgroup aware workqueues Bandan Das
2016-03-18 22:14 ` [RFC PATCH 1/4] cgroup: Introduce a function to compare two tasks Bandan Das
2016-03-18 22:14 ` [RFC PATCH 2/4] workqueue: introduce support for attaching to cgroups Bandan Das
2016-03-18 22:14 ` [RFC PATCH 3/4] cgroup: use spin_lock_irq for cgroup match and attach fns Bandan Das
2016-03-18 22:14 ` [RFC PATCH 4/4] vhost: use workqueues for the works Bandan Das
2016-03-20 18:10 ` [RFC PATCH 0/4] cgroup aware workqueues Tejun Heo
2016-03-21 17:35   ` Bandan Das
2016-03-21  7:58 ` Michael Rapoport
2016-03-21 17:43   ` Bandan Das [this message]
2016-03-22  7:12     ` vhost threading model (was: Re: [RFC PATCH 0/4] cgroup aware workqueues) Michael Rapoport
2016-03-22  7:12       ` Michael Rapoport
2016-03-22  7:12     ` Michael Rapoport
2016-03-22 19:00       ` vhost threading model Bandan Das
2016-03-23 11:13         ` Michael Rapoport
2016-03-23 11:13         ` Michael Rapoport
2016-03-21  7:58 ` [RFC PATCH 0/4] cgroup aware workqueues Michael Rapoport
2016-03-21  7:58   ` Michael Rapoport
2016-03-21  8:29 ` Christian Borntraeger
2016-03-21 17:49   ` Bandan Das
     [not found] ` <201603210758.u2L7wiY9003907@d06av07.portsmouth.uk.ibm.com>
2016-03-30 17:04   ` Tejun Heo
2016-03-31  6:17     ` Michael Rapoport
2016-03-31  6:17     ` Michael Rapoport
2016-03-31  6:17       ` Michael Rapoport
2016-03-31 17:14       ` Tejun Heo
2016-03-31 18:45         ` Bandan Das
2016-04-03 10:43           ` Michael Rapoport
2016-04-03 10:43             ` Michael Rapoport
2016-04-03 10:43           ` Michael Rapoport
     [not found]           ` <201604031043.u33AhpSF023771@d06av06.portsmouth.uk.ibm.com>
2016-04-04 17:00             ` Bandan Das
2016-04-03 10:43         ` Michael Rapoport
2016-04-03 10:43         ` Michael Rapoport
2016-05-27  9:22         ` Michael Rapoport
2016-05-27 14:17           ` Tejun Heo
2016-05-27  9:22         ` Michael Rapoport

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jpg1t73d8vm.fsf@linux.bootlegged.copy \
    --to=bsd@redhat.com \
    --cc=RAPOPORT@il.ibm.com \
    --cc=jiangshanlai@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.