Re: [RFC PATCH 0/4] cgroup aware workqueues

From	Bandan Das <bsd@redhat.com>
Newsgroups	linux.kernel
Subject	Re: [RFC PATCH 0/4] cgroup aware workqueues
Date	2016-03-31 20:50 +0200
Message-ID	<riPPj-IR-1@gated-at.bofh.it> (permalink)
References	<reaUp-1RE-7@gated-at.bofh.it> <rirN1-87-35@gated-at.bofh.it> <rirN1-87-33@gated-at.bofh.it> <riE7w-G2-11@gated-at.bofh.it> <riOqe-8lu-13@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

Tejun Heo <tj@kernel.org> writes:

> Hello, Michael.
>
> On Thu, Mar 31, 2016 at 08:17:13AM +0200, Michael Rapoport wrote:
>> > 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.
>
> I'd be happy to help digging into what's going on.  If kvm wants full
> control over the worker thread, kvm can use workqueue as a pure
> threadpool.  Schedule a work item to grab a worker thread with the
> matching attributes and keep using it as it'd a kthread.  While that
> wouldn't be able to take advantage of work item flushing and so on,
> it'd still be a simpler way to manage worker threads and the extra
> stuff like cgroup membership handling doesn't have to be duplicated.
>
>> > > 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.
>
> Yeah, if that actually is beneficial, take full control of the
> kworker thread.

Well, even if it actually is beneficial (which I am sure it is), it seems a
little impractical to block current improvements based on a future prospect
that (as far as I know), no one is working on ?

There have been discussions about this in the past and iirc, most people agree
about not going the byos* route. But I am still all for such a proposal and if
it's good/clean enough, I think we can definitely tear down what we have and
throw it away! The I/O scheduling part is intrusive enough that even the current
code base has to be changed quite a bit.

*byos = bring your own scheduling ;)

> Thanks.

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[RFC PATCH 0/4] cgroup aware workqueues Bandan Das <bsd@redhat.com> - 2016-03-18 23:20 +0100
  Re: [RFC PATCH 0/4] cgroup aware workqueues Tejun Heo <tj@kernel.org> - 2016-03-20 19:20 +0100
    Re: [RFC PATCH 0/4] cgroup aware workqueues Bandan Das <bsd@redhat.com> - 2016-03-21 18:40 +0100
  Re: [RFC PATCH 0/4] cgroup aware workqueues "Michael Rapoport" <RAPOPORT@il.ibm.com> - 2016-03-21 09:00 +0100
  Re: [RFC PATCH 0/4] cgroup aware workqueues Christian Borntraeger <borntraeger@de.ibm.com> - 2016-03-21 09:30 +0100
    Re: [RFC PATCH 0/4] cgroup aware workqueues Bandan Das <bsd@redhat.com> - 2016-03-21 19:00 +0100
  Re: [RFC PATCH 0/4] cgroup aware workqueues Bandan Das <bsd@redhat.com> - 2016-03-21 18:50 +0100
    vhost threading model (was: Re: [RFC PATCH 0/4] cgroup aware workqueues) "Michael Rapoport" <RAPOPORT@il.ibm.com> - 2016-03-22 08:20 +0100
    Re: vhost threading model Bandan Das <bsd@redhat.com> - 2016-03-22 20:10 +0100
      Re: vhost threading model "Michael Rapoport" <RAPOPORT@il.ibm.com> - 2016-03-23 12:20 +0100
  Re: [RFC PATCH 0/4] cgroup aware workqueues Tejun Heo <tj@kernel.org> - 2016-03-30 19:10 +0200
    Re: [RFC PATCH 0/4] cgroup aware workqueues "Michael Rapoport" <RAPOPORT@il.ibm.com> - 2016-03-31 08:20 +0200
      Re: [RFC PATCH 0/4] cgroup aware workqueues Tejun Heo <tj@kernel.org> - 2016-03-31 19:20 +0200
        Re: [RFC PATCH 0/4] cgroup aware workqueues Bandan Das <bsd@redhat.com> - 2016-03-31 20:50 +0200

csiph-web