On 2018/01/26 12:31, Wei Wang wrote: > On 01/26/2018 10:42 AM, Michael S. Tsirkin wrote: >> On Fri, Jan 26, 2018 at 09:40:44AM +0800, Wei Wang wrote: >>> On 01/25/2018 09:49 PM, Michael S. Tsirkin wrote: >>>> On Thu, Jan 25, 2018 at 05:14:06PM +0800, Wei Wang wrote: >>>> > >>> The controversy is that the free list is not static >>> once the lock is dropped, so everything is dynamically changing, including >>> the state that was recorded. The method we are using is more prudent, IMHO. >>> How about taking the fundamental solution, and seek to improve incrementally >>> in the future? >>> >>> >>> Best, >>> Wei >> I'd like to see kicks happen outside the spinlock. kick with a spinlock >> taken looks like a scalability issue that won't be easy to >> reproduce but hurt workloads at random unexpected times. >> > > Is that "kick inside the spinlock" the only concern you have? I think we can > remove the kick actually. If we check how the host side works, it is > worthwhile to let the host poll the virtqueue after it receives the cmd id > from the guest (kick for cmd id isn't within the lock).
We should start from the worst case. + * The callback itself must not sleep or perform any operations which would + * require any memory allocations directly (not even GFP_NOWAIT/GFP_ATOMIC) + * or via any lock dependency. It is generally advisable to implement + * the callback as simple as possible and defer any heavy lifting to a + * different context. Making decision based on performance numbers of idle guests is dangerous. There might be busy CPUs waiting for zone->lock.
