Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-19 Thread Stefano Stabellini
On Thu, 18 May 2017, Stefano Stabellini wrote: > On Wed, 17 May 2017, Juergen Gross wrote: > > On 16/05/17 21:58, Stefano Stabellini wrote: > > > On Tue, 16 May 2017, Juergen Gross wrote: > > >> On 15/05/17 22:35, Stefano Stabellini wrote: > > >>> The pvcalls backend has one ioworker per cpu: the i

Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-18 Thread Stefano Stabellini
On Wed, 17 May 2017, Juergen Gross wrote: > On 16/05/17 21:58, Stefano Stabellini wrote: > > On Tue, 16 May 2017, Juergen Gross wrote: > >> On 15/05/17 22:35, Stefano Stabellini wrote: > >>> The pvcalls backend has one ioworker per cpu: the ioworkers are > >>> implemented as a cpu bound workqueue,

Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-16 Thread Juergen Gross
On 16/05/17 21:58, Stefano Stabellini wrote: > On Tue, 16 May 2017, Juergen Gross wrote: >> On 15/05/17 22:35, Stefano Stabellini wrote: >>> The pvcalls backend has one ioworker per cpu: the ioworkers are >>> implemented as a cpu bound workqueue, and will deal with the actual >>> socket and data ri

Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-16 Thread Stefano Stabellini
On Tue, 16 May 2017, Stefano Stabellini wrote: > > And why are you using a rw semaphore --- I only noticed two instances of use > > and both are writes. > > Yes, this is wrong, legacy from a previous version of the codebase. A > simple spin_lock should suffice for this use-case. I replied too qui

Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-16 Thread Stefano Stabellini
On Mon, 15 May 2017, Boris Ostrovsky wrote: > On 05/15/2017 04:35 PM, Stefano Stabellini wrote: > > The pvcalls backend has one ioworker per cpu: the ioworkers are > > implemented as a cpu bound workqueue, and will deal with the actual > > socket and data ring reads/writes. > > > > ioworkers are g

Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-16 Thread Stefano Stabellini
On Tue, 16 May 2017, Juergen Gross wrote: > On 15/05/17 22:35, Stefano Stabellini wrote: > > The pvcalls backend has one ioworker per cpu: the ioworkers are > > implemented as a cpu bound workqueue, and will deal with the actual > > socket and data ring reads/writes. > > > > ioworkers are global:

Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-15 Thread Juergen Gross
On 15/05/17 22:35, Stefano Stabellini wrote: > The pvcalls backend has one ioworker per cpu: the ioworkers are > implemented as a cpu bound workqueue, and will deal with the actual > socket and data ring reads/writes. > > ioworkers are global: we only have one set for all the frontends. They > pro

Re: [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-15 Thread Boris Ostrovsky
On 05/15/2017 04:35 PM, Stefano Stabellini wrote: The pvcalls backend has one ioworker per cpu: the ioworkers are implemented as a cpu bound workqueue, and will deal with the actual socket and data ring reads/writes. ioworkers are global: we only have one set for all the frontends. They proces

[PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

2017-05-15 Thread Stefano Stabellini
The pvcalls backend has one ioworker per cpu: the ioworkers are implemented as a cpu bound workqueue, and will deal with the actual socket and data ring reads/writes. ioworkers are global: we only have one set for all the frontends. They process requests on their wqs list in order, once they are d