Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1565246

Re: [PATCH v3 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

Show all headers | View raw

On 01/23/2017 05:09 AM, Juergen Gross wrote:
> Handling of multiple concurrent Xenstore accesses through xenbus driver
> either from the kernel or user land is rather lame today: xenbus is
> capable to have one access active only at one point of time.
>
> Rewrite xenbus to handle multiple requests concurrently by making use
> of the request id of the Xenstore protocol. This requires to:
>
> - Instead of blocking inside xb_read() when trying to read data from
>   the xenstore ring buffer do so only in the main loop of
>   xenbus_thread().
>
> - Instead of doing writes to the xenstore ring buffer in the context of
>   the caller just queue the request and do the write in the dedicated
>   xenbus thread.
>
> - Instead of just forwarding the request id specified by the caller of
>   xenbus to xenstore use a xenbus internal unique request id. This will
>   allow multiple outstanding requests.
>
> - Modify the locking scheme in order to allow multiple requests being
>   active in parallel.
>
> - Instead of waiting for the reply of a user's xenstore request after
>   writing the request to the xenstore ring buffer return directly to
>   the caller and do the waiting in the read path.
>
> Additionally signal handling was optimized by avoiding waking up the
> xenbus thread or sending an event to Xenstore in case the addressed
> entity is known to be running already.
>
> As a result communication with Xenstore is sped up by a factor of up
> to 5: depending on the request type (read or write) and the amount of
> data transferred the gain was at least 20% (small reads) and went up to
> a factor of 5 for large writes.
>
> In the end some more rough edges of xenbus have been smoothed:
>
> - Handling of memory shortage when reading from xenstore ring buffer in
>   the xenbus driver was not optimal: it was busy looping and issuing a
>   warning in each loop.
>
> - In case of xenstore not running in dom0 but in a stubdom we end up
>   with two xenbus threads running as the initialization of xenbus in
>   dom0 expecting a local xenstored will be redone later when connecting
>   to the xenstore domain. Up to now this was no problem as locking
>   would prevent the two xenbus threads interfering with each other, but
>   this was just a waste of kernel resources.
>
> - An out of memory situation while writing to or reading from the
>   xenstore ring buffer no longer will lead to a possible loss of
>   synchronization with xenstore.
>
> - The user read and write part are now interruptible by signals.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH v3 0/3] xen: optimize xenbus performance Juergen Gross <jgross@suse.com> - 2017-01-23 11:10 +0100
  [PATCH v3 2/3] xen: modify xenstore watch event interface Juergen Gross <jgross@suse.com> - 2017-01-23 11:10 +0100
  [PATCH v3 1/3] xen: clean up xenbus internal headers Juergen Gross <jgross@suse.com> - 2017-01-23 11:20 +0100
  Re: [PATCH v3 3/3] xen: optimize xenbus driver for multiple  concurrent xenstore accesses Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-23 20:00 +0100
    Re: [PATCH v3 3/3] xen: optimize xenbus driver for multiple  concurrent xenstore accesses Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-24 14:50 +0100
      Re: [PATCH v3 3/3] xen: optimize xenbus driver for multiple  concurrent xenstore accesses Juergen Gross <jgross@suse.com> - 2017-01-24 17:30 +0100

csiph-web