Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1360966 > unrolled thread

[RFC PATCH 0/4] cgroup aware workqueues

Back to article view | Back to linux.kernel

Contents

  [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

#1360966 — [RFC PATCH 0/4] cgroup aware workqueues

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.

Accounting:
When servicing a userspace task A attached to cgroup X, for cgroup
awareness, a worker thread could attach to all cgroups
of the task which it is servicing. This patch does it for unbound
workqueues which means all tasks that are bound to certain cgroups
could potentially be serviced by the same worker thread. However,
the same technique could be applicable to bounded workqueues as
well.

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.

Design:

The fundamental addition is a cgroup aware worker pool and as stated above,
for the unbounded case only.

These changes don't populate the "numa awareness" fields/attrs and
unlike unbounded numa worker pools, cgroup worker pools are created
on demand. Every work request could potentially have a new cgroup
aware pool created for it based on the combination of cgroups it's attached
to. However, workqueues themselves are incognizant of the actual cgroups -
they rely on the cgroups provided helper functions either for 1. a match
of all the cgroups or 2. to attach a worker thread to all cgroups of
a userspace task. We do maintain a list of cgroup aware pools so that
when a new request comes in and a suitable worker pool needs to be
found, we search the list first before creating a new one. A worker
pool also stores a a list of all "task owners" - a list of processes
that we are serving currently.

Testing:
Create some qemu processes and attaching them to different
cgroups. Verifying that new worker pools are created for tasks
that are attached to different cgroups (and reuse for the ones
that belong to the same).

Some simple performace testing using netperf below. Although, these
numbers shouldn't be dependent on these patches. The cgroup attach
and match functions are not in hot paths for general usage which
is what this test does.

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

Todo:
What about bounded workqueues ?
What happens when cgroups of a running process changes ?
sysfs variables
Sanity check the flush and destroy path.
More extensive testing
Can we optimize the search/match/attach functions ?
Better performance numbers ? (although the onese above don't look bad)

[1] http://events.linuxfoundation.org/sites/events/files/slides/kvm_forum_2015_vhost_sharing_is_better.pdf

Bandan Das (4):
  cgroup: Introduce a function to compare two tasks
  workqueue: introduce support for attaching to cgroups
  cgroup: use spin_lock_irq for cgroup match and attach fns
  vhost: use workqueues for the works

 drivers/vhost/vhost.c       | 103 ++++++++++++++++++---
 drivers/vhost/vhost.h       |   2 +
 include/linux/cgroup.h      |   1 +
 include/linux/workqueue.h   |   2 +
 kernel/cgroup.c             |  40 ++++++++-
 kernel/workqueue.c          | 212 +++++++++++++++++++++++++++++++++++++++++---
 kernel/workqueue_internal.h |   4 +
 7 files changed, 335 insertions(+), 29 deletions(-)

-- 
2.5.0

[toc] | [next] | [standalone]

#1361344

Hello,

On Fri, Mar 18, 2016 at 06:14:47PM -0400, Bandan Das wrote:
> These changes don't populate the "numa awareness" fields/attrs and
> unlike unbounded numa worker pools, cgroup worker pools are created
> on demand. Every work request could potentially have a new cgroup

Hmmm... I don't get it.  Why would this be exclusive with numa
support?  Can't cgroup be just another attribute in addition to numa?

> aware pool created for it based on the combination of cgroups it's attached
> to. However, workqueues themselves are incognizant of the actual cgroups -
> they rely on the cgroups provided helper functions either for 1. a match
> of all the cgroups or 2. to attach a worker thread to all cgroups of
> a userspace task. We do maintain a list of cgroup aware pools so that
> when a new request comes in and a suitable worker pool needs to be
> found, we search the list first before creating a new one. A worker
> pool also stores a a list of all "task owners" - a list of processes
> that we are serving currently.

Why is this separate from the normal lookup mechanism?  Can't it be
hashed together?

> Todo:
> What about bounded workqueues ?

I don't think it'd matter.  This is only interesting for work items
which may consume a significant amount of resources, which shouldn't
be served by per-cpu workers anyway.

> What happens when cgroups of a running process changes ?

Existing work items will be served with the old association.  New work
items will be served with the new association.  This is consistent
with how other attributes are handled too.

> Better performance numbers ? (although the onese above don't look bad)

Where is performance regression coming from?  Why is there *any*
performance penalty?

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1362037

Tejun Heo <tj@kernel.org> writes:

> Hello,
>
> On Fri, Mar 18, 2016 at 06:14:47PM -0400, Bandan Das wrote:
>> These changes don't populate the "numa awareness" fields/attrs and
>> unlike unbounded numa worker pools, cgroup worker pools are created
>> on demand. Every work request could potentially have a new cgroup
>
> Hmmm... I don't get it.  Why would this be exclusive with numa
> support?  Can't cgroup be just another attribute in addition to numa?

Yes, I think it can. I am not certain what would be a good representation
of the cgroup information; maybe, all cgroups could be represented by just a
simple bitmap just like numa attrs ? The other thing that was on my mind is
what happens when there's no intersection between the cgroups
of a task and the numa locality. For example, if node 1 with cpus 0,1,2,3 is local to
task A but it's cgroups want to attach to cpus 4-5, then who wins in this case ?
Or a simple logic would be to always attach to cgroups as the last step.


>> aware pool created for it based on the combination of cgroups it's attached
>> to. However, workqueues themselves are incognizant of the actual cgroups -
>> they rely on the cgroups provided helper functions either for 1. a match
>> of all the cgroups or 2. to attach a worker thread to all cgroups of
>> a userspace task. We do maintain a list of cgroup aware pools so that
>> when a new request comes in and a suitable worker pool needs to be
>> found, we search the list first before creating a new one. A worker
>> pool also stores a a list of all "task owners" - a list of processes
>> that we are serving currently.
>
> Why is this separate from the normal lookup mechanism?  Can't it be
> hashed together?
>
>> Todo:
>> What about bounded workqueues ?
>
> I don't think it'd matter.  This is only interesting for work items
> which may consume a significant amount of resources, which shouldn't
> be served by per-cpu workers anyway.

Ok.

>> What happens when cgroups of a running process changes ?
>
> Existing work items will be served with the old association.  New work
> items will be served with the new association.  This is consistent
> with how other attributes are handled too.

In the current implementation, the cgroup info is fetched just once
when alloc_workqueue is called. So, there's no way of knowing if the
cgroups changed. Maybe I should rethink this too.

>> Better performance numbers ? (although the onese above don't look bad)
>
> Where is performance regression coming from?  Why is there *any*
> performance penalty?

I am still investigating this but creating more worker threads could
be one.

/* do  we need to manage? */                                                                                                                                                                                
        if (unlikely(!may_start_working(pool)) && manage_workers(worker))
           goto recheck;                         

Since all work gets queued to the default pwq in this implementation,
we do end up creating workers in the middle of a run.

> Thanks.

[toc] | [prev] | [next] | [standalone]

#1361567

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.

[toc] | [prev] | [next] | [standalone]

#1361596

On 03/18/2016 11:14 PM, Bandan Das wrote:
[..]
> 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

So TCP stream stays the same everything else shows a regression? Not good.
Have you an idea why this happens?

[toc] | [prev] | [next] | [standalone]

#1362050

Christian Borntraeger <borntraeger@de.ibm.com> writes:

> On 03/18/2016 11:14 PM, Bandan Das wrote:
> [..]
>> 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
>
> So TCP stream stays the same everything else shows a regression? Not good.
> Have you an idea why this happens?

I am not sure yet but my guess is the way these patches implement cgroup
support. I will run some tests just with workqueues (and without these patches) and
see if the newer numbers are consistent with these.

[toc] | [prev] | [next] | [standalone]

#1362043

"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

[toc] | [prev] | [next] | [standalone]

#1362361 — vhost threading model (was: Re: [RFC PATCH 0/4] cgroup aware workqueues)

>  Bandan Das <bsd@redhat.com> wrote on 03/21/2016 07:43:41 PM:
> > "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.

Agree. Didn't have time to do it myself yet...

> Which patches did you use ? Note that an earlier version of workqueue 
patches
> that I posted used per-cpu workqueues.

I've used your earlier version of workqueue patches, then I modified it to 
use unbound workqueues, and then I even restored to some extent original 
vhost workqueue usage. In all the cases I saw performance degradation 
relatively to the baseline.
 
> > 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.

Well, Elvis is a _theoretical_ example that showed that I/O scheduling in 
the vhost improves performance.
I'm not saying we should take Evlis and try to squeeze it into the vhost, 
I just want to say that we cannot switch vhost to use workqueues if it 
causes performance degradation.

My opinion is that we need to give it some more thought, much more 
performance evaluation, so that we can find the best model.
 
> > 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.
> > 

--
Sincerely yours,
Mike.

[toc] | [prev] | [next] | [standalone]

#1362918 — Re: vhost threading model

"Michael Rapoport" <RAPOPORT@il.ibm.com> writes:
...
>
> Well, Elvis is a _theoretical_ example that showed that I/O scheduling in 
> the vhost improves performance.
> I'm not saying we should take Evlis and try to squeeze it into the vhost, 
> I just want to say that we cannot switch vhost to use workqueues if it 
> causes performance degradation.
>
> My opinion is that we need to give it some more thought, much more 
> performance evaluation, so that we can find the best model.

Exactly, I think we are outright discarding using workqueues even
without investigating it in detail even though it would be a cleaner
implementation using a common framework and thereby more chances of
an acceptable solution for upstream.

Anyway, if we don't want to go the workqueues way for vhost, cgroups
support for workqueues is still something worth having on its own.

>> > 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.
>> > 
>
> --
> 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

[toc] | [prev] | [next] | [standalone]

#1363342 — Re: vhost threading model

> Bandan Das <bsd@redhat.com> wrote on 03/22/2016 09:00:50 PM:
> > "Michael Rapoport" <RAPOPORT@il.ibm.com> writes:
> >
> > Well, Elvis is a _theoretical_ example that showed that I/O scheduling 
in 
> > the vhost improves performance.
> > I'm not saying we should take Evlis and try to squeeze it into the 
vhost, 
> > I just want to say that we cannot switch vhost to use workqueues if it 

> > causes performance degradation.
> >
> > My opinion is that we need to give it some more thought, much more 
> > performance evaluation, so that we can find the best model.
> 
> Exactly, I think we are outright discarding using workqueues even
> without investigating it in detail even though it would be a cleaner
> implementation using a common framework and thereby more chances of
> an acceptable solution for upstream.

I'm not suggesting to discard using workqueues.
All I'm saying that among several options for vhost threading model we 
should find the one with best "performance/complexity" ratio :)
 
> Anyway, if we don't want to go the workqueues way for vhost, cgroups
> support for workqueues is still something worth having on its own.

No objection to that.
 
> >> > 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.
> >> > 
> >

[toc] | [prev] | [next] | [standalone]

#1367469

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.

> opportunity for optimization, at least for some workloads...

What sort of optimizations are we talking about?

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1367834

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.

[toc] | [prev] | [next] | [standalone]

#1368462

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.

Thanks.

-- 
tejun

[toc] | [prev] | [next] | [standalone]

#1368537

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web