From: Mike Christie <michael.christie@oracle.com>
To: martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
target-devel@vger.kernel.org, mst@redhat.com,
jasowang@redhat.com, pbonzini@redhat.com, stefanha@redhat.com,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 12/16] vhost: support multiple worker threads
Date: Thu, 08 Oct 2020 17:56:53 +0000 [thread overview]
Message-ID: <da6f25b4-7a98-9294-a987-43d100625499@oracle.com> (raw)
In-Reply-To: <1602104101-5592-13-git-send-email-michael.christie@oracle.com>
On 10/7/20 3:54 PM, Mike Christie wrote:
> This is a prep patch to support multiple vhost worker threads per vhost
> dev. This patch converts the code that had assumed a single worker
> thread by:
>
> 1. Moving worker related fields to a new struct vhost_worker.
> 2. Converting vhost.c code to use the new struct and assume we will
> have an array of workers.
> 3. It also exports a helper function that will be used in the last
> patch when vhost-scsi is converted to use this new functionality.
>
Oh yeah I also wanted to bring up this patch:
https://www.spinics.net/lists/netdev/msg192548.html
The problem with my multi-threading patches is that I was focused on
the cgroup support parts and that lead to some gross decisions.
1. I kept the cgroup support, but as a result I do not have control
over the threading affinity and making sure cmds are executed on a
optimal CPU like the above patches do.
When I drop the cgroup support and make sure threads are bound to
specific CPUs and then make sure IO is run on the CPU it came in on
then IOPs jumps from 600K to 800K for vhost-scsi.
2. I can possible create a lot of threads.
So a couple open issues are:
1. Can we do a thread per cpu that is shared across all vhost devices?
That would lead to dropping the cgroup vhost worker support.
2. Can we just use the kernel's workqueues then?
WARNING: multiple messages have this Message-ID (diff)
From: Mike Christie <michael.christie@oracle.com>
To: martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
target-devel@vger.kernel.org, mst@redhat.com,
jasowang@redhat.com, pbonzini@redhat.com, stefanha@redhat.com,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 12/16] vhost: support multiple worker threads
Date: Thu, 8 Oct 2020 12:56:53 -0500 [thread overview]
Message-ID: <da6f25b4-7a98-9294-a987-43d100625499@oracle.com> (raw)
In-Reply-To: <1602104101-5592-13-git-send-email-michael.christie@oracle.com>
On 10/7/20 3:54 PM, Mike Christie wrote:
> This is a prep patch to support multiple vhost worker threads per vhost
> dev. This patch converts the code that had assumed a single worker
> thread by:
>
> 1. Moving worker related fields to a new struct vhost_worker.
> 2. Converting vhost.c code to use the new struct and assume we will
> have an array of workers.
> 3. It also exports a helper function that will be used in the last
> patch when vhost-scsi is converted to use this new functionality.
>
Oh yeah I also wanted to bring up this patch:
https://www.spinics.net/lists/netdev/msg192548.html
The problem with my multi-threading patches is that I was focused on
the cgroup support parts and that lead to some gross decisions.
1. I kept the cgroup support, but as a result I do not have control
over the threading affinity and making sure cmds are executed on a
optimal CPU like the above patches do.
When I drop the cgroup support and make sure threads are bound to
specific CPUs and then make sure IO is run on the CPU it came in on
then IOPs jumps from 600K to 800K for vhost-scsi.
2. I can possible create a lot of threads.
So a couple open issues are:
1. Can we do a thread per cpu that is shared across all vhost devices?
That would lead to dropping the cgroup vhost worker support.
2. Can we just use the kernel's workqueues then?
next prev parent reply other threads:[~2020-10-08 17:56 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-07 20:54 [PATCH 00/16 V2] vhost: fix scsi cmd handling and IOPs Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 01/16] vhost scsi: add lun parser helper Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 02/16] vhost: remove work arg from vhost_work_flush Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 03/16] vhost net: use goto error handling in open Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 04/16] vhost: prep vhost_dev_init users to handle failures Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-08 0:58 ` kernel test robot
2020-10-08 0:58 ` kernel test robot
2020-10-08 0:58 ` kernel test robot
2020-10-08 0:58 ` kernel test robot
2020-10-09 11:41 ` Dan Carpenter
2020-10-09 11:41 ` Dan Carpenter
2020-10-09 11:41 ` Dan Carpenter
2020-10-09 11:41 ` Dan Carpenter
2020-10-09 11:41 ` Dan Carpenter
2020-10-23 15:56 ` Michael S. Tsirkin
2020-10-23 15:56 ` Michael S. Tsirkin
2020-10-23 15:56 ` Michael S. Tsirkin
2020-10-23 15:56 ` Michael S. Tsirkin
2020-10-23 16:21 ` Mike Christie
2020-10-23 16:21 ` Mike Christie
2020-10-23 16:21 ` Mike Christie
2020-10-07 20:54 ` [PATCH 05/16] vhost: move vq iovec allocation to dev init time Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 06/16] vhost: support delayed vq creation Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 07/16] vhost scsi: support delayed IO " Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 08/16] vhost scsi: alloc cmds per vq instead of session Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 09/16] vhost scsi: fix cmd completion race Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 10/16] vhost scsi: Add support for LUN resets Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 11/16] vhost scsi: remove extra flushes Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 12/16] vhost: support multiple worker threads Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-08 17:56 ` Mike Christie [this message]
2020-10-08 17:56 ` Mike Christie
2020-10-08 20:26 ` Michael S. Tsirkin
2020-10-08 20:26 ` Michael S. Tsirkin
2020-10-08 20:26 ` Michael S. Tsirkin
2020-10-07 20:54 ` [PATCH 13/16] vhost poll: fix coding style Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-07 20:54 ` [PATCH 14/16] vhost: poll support support multiple workers Mike Christie
2020-10-07 20:54 ` Mike Christie
2020-10-08 0:46 ` kernel test robot
2020-10-08 0:46 ` kernel test robot
2020-10-08 0:46 ` kernel test robot
2020-10-08 0:46 ` kernel test robot
2020-10-23 15:43 ` Michael S. Tsirkin
2020-10-23 15:43 ` Michael S. Tsirkin
2020-10-23 15:43 ` Michael S. Tsirkin
2020-10-23 15:43 ` Michael S. Tsirkin
2020-10-07 20:55 ` [PATCH 15/16] vhost scsi: make completion per vq Mike Christie
2020-10-07 20:55 ` Mike Christie
2020-10-07 20:55 ` [PATCH 16/16] vhost scsi: multiple worker support Mike Christie
2020-10-07 20:55 ` Mike Christie
2020-10-23 15:46 ` [PATCH 00/16 V2] vhost: fix scsi cmd handling and IOPs Michael S. Tsirkin
2020-10-23 15:46 ` Michael S. Tsirkin
2020-10-23 15:46 ` Michael S. Tsirkin
2020-10-23 16:22 ` Mike Christie
2020-10-23 16:22 ` Mike Christie
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=da6f25b4-7a98-9294-a987-43d100625499@oracle.com \
--to=michael.christie@oracle.com \
--cc=jasowang@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=target-devel@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.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.