On Thu, Oct 08, 2020 at 12:56:53PM -0500, Mike Christie wrote: > 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? Problem is, we are talking about *lots* of CPU, IO etc and ATM cgroups is how people expect to account for that overhead.
