"Michael Rapoport" <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Bandan Das <[email protected]> wrote on 03/22/2016 09:00:50 PM:
> > "Michael Rapoport" <[email protected]> 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.
> >> >
> >