On 6/14/23 1:02 AM, Eric W. Biederman wrote: > > I am sad my idea for simplifying things did not work out. > > > Let's try an even bigger idea to reduce maintenance and simplify things. > > Could vhost depend on io_uring? > > Could vhost just be a translation layer of existing vhost requests to > io_uring requests? > > At a quick glance it looks like io_uring already supports the > functionality that vhost supports (which I think is networking and > scsi). > > If vhost could become a translation layer that would allow removing > the vhost worker and PF_USER_WORKER could be removed completely, > leaving only PF_IO_WORKER. > > > I suggest this because a significant vhost change is needed because in It would be nice if the vhost layer could use the io-wq code as sort of generic worker. I can look into what that would take if Jens is ok with that type of thing. For vhost, I just submitted a patch to the vhost layer that allow us to switch out the vhost worker thread when IO is running: https://lists.linuxfoundation.org/pipermail/virtualization/2023-June/067246.html After that patch, I just need to modify vhost_worker/vhost_task_fn so when get_signal returns true we set the worker to NULL and do a synchronize_rcu. Then I just need to modify vhost-scsi so it detects when the worker is NULL and modify the flush code so it handles work that didn't get to run. > the long term the hacks in exec and coredump are not a good idea. Which > means something like my failed "[PATCH v3] fork, vhost: Use CLONE_THREAD > to fix freezer/ps regression". > > If we have to go to all of the trouble of reworking things it why can't > we just make io_uring do all of the work? > > Eric _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization