From: Juergen Gross <jgross@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses
Date: Wed, 8 Feb 2017 07:21:29 +0100 [thread overview]
Message-ID: <f7f4a616-4089-51f7-08be-d2bacedf7caa__29162.7870909453$1486535006$gmane$org@suse.com> (raw)
In-Reply-To: <34056227-cffb-fe01-ee79-8f9a40a90ea0@oracle.com>
On 07/02/17 23:39, Boris Ostrovsky wrote:
> On 02/07/2017 12:51 PM, Boris Ostrovsky wrote:
>> On 01/24/2017 11:23 AM, Juergen Gross wrote:
>>> On 24/01/17 14:47, Boris Ostrovsky wrote:
>>>> On 01/23/2017 01:59 PM, Boris Ostrovsky wrote:
>>>>> 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.
>>>>>>
>>>>>>
>>>> This patch appears to break save/restore:
>>> Hmm, tried multiple times, but I can't reproduce this issue.
>>>
>>> Anything special in the setup? I tried a 64 bit pv guest and did
>>> "xl save".
>>>
>>> Do I have to run some load in parallel?
>> Any luck reproducing this? I am still failing the test on dumpdata but I
>> couldn't reproduce it on another system.
>
>
> The problem appears to be xs_state_users being non-zero when we call
> xs_suspend_enter().
>
> From what I understand this is caused by xs_request_exit() not
> decrementing it when closing a transaction. This seems to be happening
> when XS_TRANSACTION_END transaction returns XS_ERROR (I haven't traced
> what causes this error but it doesn't appear to cause any visible harm).
Aah, of course: this will happen for a transaction failing due to a
conflict (EAGAIN case).
> Does the patch below make sense?
As the xenbus driver is checking for the transaction id to be valid this
is okay, I think.
I have noticed another problem, though: a user client mixing Xenstore
accesses with and without transactions could be blocked when doing a
non-transactional access hindering it from completing the transaction.
I'll send an updated version including your fix.
>
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index e62cb09..ffd5fac 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -140,7 +140,7 @@ void xs_request_exit(struct xb_req_data *req)
> spin_lock(&xs_state_lock);
> xs_state_users--;
> if ((req->type == XS_TRANSACTION_START && req->msg.type ==
> XS_ERROR) ||
> - req->msg.type == XS_TRANSACTION_END)
> + req->type == XS_TRANSACTION_END)
> xs_state_users--;
> spin_unlock(&xs_state_lock);
>
>
> I ran a few tests on dumpdata and they completed successfully. I'll keep
> this for the overnight runs too, with a different Xen version.
Thanks.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-02-08 6:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-23 10:09 [PATCH v3 0/3] xen: optimize xenbus performance Juergen Gross
2017-01-23 10:09 ` [PATCH v3 1/3] xen: clean up xenbus internal headers Juergen Gross
2017-01-23 10:09 ` Juergen Gross
2017-01-23 10:09 ` [PATCH v3 2/3] xen: modify xenstore watch event interface Juergen Gross
2017-01-23 10:09 ` Juergen Gross
2017-01-23 10:09 ` [PATCH v3 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Juergen Gross
2017-01-23 10:09 ` Juergen Gross
2017-01-23 18:59 ` Boris Ostrovsky
2017-01-23 18:59 ` Boris Ostrovsky
2017-01-24 13:47 ` Boris Ostrovsky
2017-01-24 16:23 ` Juergen Gross
2017-01-24 16:23 ` Juergen Gross
2017-01-24 17:17 ` Boris Ostrovsky
2017-01-24 17:17 ` Boris Ostrovsky
2017-02-07 17:51 ` Boris Ostrovsky
2017-02-07 17:51 ` Boris Ostrovsky
2017-02-07 22:39 ` Boris Ostrovsky
2017-02-07 22:39 ` Boris Ostrovsky
2017-02-08 6:21 ` Juergen Gross [this message]
2017-02-08 6:21 ` Juergen Gross
2017-01-24 13:47 ` Boris Ostrovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='f7f4a616-4089-51f7-08be-d2bacedf7caa__29162.7870909453$1486535006$gmane$org@suse.com' \
--to=jgross@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.