lkml.org 
[lkml]   [2021]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2021-01-12 07:06    [W:1.639 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site