[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210112172901.ilp7vf3hqmbvav7y@offworld>
Date: Tue, 12 Jan 2021 09:29:01 -0800
From: Davidlohr Bueso <dave@...olabs.net>
To: Shuo A Liu <shuo.a.liu@...el.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"H . Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Yu Wang <yu1.wang@...el.com>,
Reinette Chatre <reinette.chatre@...el.com>,
Zhi Wang <zhi.a.wang@...el.com>,
Zhenyu Wang <zhenyuw@...ux.intel.com>
Subject: Re: [PATCH v7 09/18] virt: acrn: Introduce I/O request management
On Tue, 12 Jan 2021, Shuo A Liu wrote:
>On Mon 11.Jan'21 at 13:52:19 -0800, Davidlohr Bueso wrote:
>>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.
Yes, there is some added latency between when the work is scheduled and
actually executed - however this should not be a problem for this scenario,
and furthermore consider that tasklets do not guarantee performance as
ksoftirqd comes in the picture under heavy load.
Thanks,
Davidlohr
Powered by blists - more mailing lists