Messages in this thread | | | Date | Tue, 12 Jan 2021 14:05:27 +0800 | From | Shuo A Liu <> | Subject | Re: [PATCH v7 09/18] virt: acrn: Introduce I/O request management |
| |
On Mon 11.Jan'21 at 13:52:19 -0800, Davidlohr Bueso wrote: >On Wed, 06 Jan 2021, shuo.a.liu@intel.com wrote: >>The processing flow of I/O requests are listed as following: >> >>a) The I/O handler of the hypervisor will fill an I/O request with >> PENDING state when a trapped I/O access happens in a User VM. >>b) The hypervisor makes an upcall, which is a notification interrupt, to >> the Service VM. >>c) The upcall handler schedules a tasklet to dispatch I/O requests. >>d) The tasklet looks for the PENDING I/O requests, assigns them to >> different registered clients based on the address of the I/O accesses, >> updates their state to PROCESSING, and notifies the corresponding >> client to handle. > >Hmm so tasklets are deprecated (and have been for a while) and it's sad >to see incoming new users in modern Linux. This wouldn't be the first one, >however. We should be _removing_ users, not adding... In addition, this >expands the whole tasklet_disable/enable() hacks.
Sorry, i had not noticed that.
> >Could this not be done in process context instead?
It could be. The original consideration with tasklet was more about performance as the I/O requests dispatching is a hot code path. I think irq thread has little performance impact? I can have a try to convert the tasklet to irq thread.
Thanks shuo
| |