On (Mon) Aug 31 2009 [08:17:21], Anthony Liguori wrote:
>>>> - A lock has to be introduced to fetch one unused buffer from the list
>>>> and pass it on to the host. And this lock has to be a spinlock, just
>>>> because writes can be called from irq context.
>>>>
>>> I don't see a problem here.
>>>
>>
>> You mean you don't see a problem in using a spinlock vs not using one?
>>
>
> Right. This isn't a fast path.
>
>> Userspace will typically send the entire buffer to be transmitted in one
>> system call. If it's large, the system call will have to be broken into
>> several. This results in multiple guest system calls, each one to be
>> handled with a spinlock held.
>>
>> Compare this with the entire write handled in one system call in the
>> current method.
>>
>
> Does it matter? This isn't a fast path.
The question isn't just about how much work happens inside the spinlock.
It's also a question about introducing spinlocks where they shouldn't
be.
I don't see why such changes have to creep into the kernel.
Can you please explain your rationale for being so rigid about merging
the two drivers?
Amit
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
