Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-05 Thread Michael S. Tsirkin
On Wed, Jun 04, 2014 at 10:51:12PM +0300, Michael S. Tsirkin wrote: On Tue, Jun 03, 2014 at 06:57:43AM -0700, Eric Dumazet wrote: On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu()

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-04 Thread Michael S. Tsirkin
On Mon, Jun 02, 2014 at 02:58:00PM -0700, Eric Dumazet wrote: On Tue, 2014-06-03 at 00:30 +0300, Michael S. Tsirkin wrote: All memory accesses are done under some VQ mutex. So lock/unlock all VQs is a faster equivalent of synchronize_rcu() for memory access changes. Some guests cause a

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-04 Thread Michael S. Tsirkin
On Tue, Jun 03, 2014 at 06:57:43AM -0700, Eric Dumazet wrote: On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. Look

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Paolo Bonzini
Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. translate_desc() still uses rcu_read_lock(), its not clear if the mutex is really held. Yes, vhost_get_vq_desc must be called with

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Vlad Yasevich
On 06/03/2014 08:48 AM, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. translate_desc() still uses rcu_read_lock(), its not clear if the mutex is really

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Paolo Bonzini
Il 03/06/2014 15:35, Vlad Yasevich ha scritto: Yes, vhost_get_vq_desc must be called with the vq mutex held. The rcu_read_lock/unlock in translate_desc is unnecessary. If that's true, then does dev-memory really needs to be rcu protected? It appears to always be read under mutex. It's

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Eric Dumazet
On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. Look at how we did this in commit c3059477fce2d956a0bb3e04357324780c5d8eeb

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-03 Thread Paolo Bonzini
Il 03/06/2014 15:57, Eric Dumazet ha scritto: On Tue, 2014-06-03 at 14:48 +0200, Paolo Bonzini wrote: Il 02/06/2014 23:58, Eric Dumazet ha scritto: This looks dubious What about using kfree_rcu() instead ? It would lead to unbound allocation from userspace. Look at how we did this in

[PULL 2/2] vhost: replace rcu with mutex

2014-06-02 Thread Michael S. Tsirkin
All memory accesses are done under some VQ mutex. So lock/unlock all VQs is a faster equivalent of synchronize_rcu() for memory access changes. Some guests cause a lot of these changes, so it's helpful to make them faster. Reported-by: Gonglei (Arei) arei.gong...@huawei.com Signed-off-by: Michael

Re: [PULL 2/2] vhost: replace rcu with mutex

2014-06-02 Thread Eric Dumazet
On Tue, 2014-06-03 at 00:30 +0300, Michael S. Tsirkin wrote: All memory accesses are done under some VQ mutex. So lock/unlock all VQs is a faster equivalent of synchronize_rcu() for memory access changes. Some guests cause a lot of these changes, so it's helpful to make them faster.