From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751421AbdAWS7h (ORCPT ); Mon, 23 Jan 2017 13:59:37 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:27878 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750997AbdAWS7f (ORCPT ); Mon, 23 Jan 2017 13:59:35 -0500 Subject: Re: [PATCH v3 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses To: Juergen Gross , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org References: <20170123100918.13523-1-jgross@suse.com> <20170123100918.13523-4-jgross@suse.com> From: Boris Ostrovsky Message-ID: <46b54be4-297a-af8f-aac2-f2a080752034@oracle.com> Date: Mon, 23 Jan 2017 13:59:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170123100918.13523-4-jgross@suse.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Reviewed-by: Boris Ostrovsky