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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
