Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1562258 > unrolled thread
| Started by | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| First post | 2017-01-19 00:00 +0100 |
| Last post | 2017-01-19 08:50 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-19 00:00 +0100
Re: [PATCH v2 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses Juergen Gross <jgross@suse.com> - 2017-01-19 08:50 +0100
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Date | 2017-01-19 00:00 +0100 |
| Subject | Re: [PATCH v2 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses |
| Message-ID | <t17mX-1Gi-39@gated-at.bofh.it> |
On 01/16/2017 09:15 AM, Juergen Gross wrote:
> +
> +static uint32_t xs_request_enter(struct xb_req_data *req)
> +{
> + uint32_t rq_id;
> +
> + req->type = req->msg.type;
> +
> + spin_lock(&xs_state_lock);
> + for (;;) {
> + if (req->msg.tx_id != 0)
> + break;
> + if (xs_suspend_active) {
> + spin_unlock(&xs_state_lock);
> + wait_event(xs_state_enter_wq, xs_suspend_active == 0);
> + spin_lock(&xs_state_lock);
> + continue;
> + }
> + if (req->type == XS_TRANSACTION_START)
> + xs_state_users++;
> + break;
> + }
> + xs_state_users++;
> + rq_id = xs_request_id++;
> + spin_unlock(&xs_state_lock);
> +
> + return rq_id;
> +}
I should have noticed this last time but I've been looking at this code
again and I don't think I understand why you are incrementing count for
XS_TRANSACTION_START inside the loop.
In fact, why not just 'while(xs_suspend_active) {}' loop?
-boris
[toc] | [next] | [standalone]
| From | Juergen Gross <jgross@suse.com> |
|---|---|
| Date | 2017-01-19 08:50 +0100 |
| Message-ID | <t1fDP-73Y-9@gated-at.bofh.it> |
| In reply to | #1562258 |
On 18/01/17 21:14, Boris Ostrovsky wrote:
> On 01/16/2017 09:15 AM, Juergen Gross wrote:
>> +
>> +static uint32_t xs_request_enter(struct xb_req_data *req)
>> +{
>> + uint32_t rq_id;
>> +
>> + req->type = req->msg.type;
>> +
>> + spin_lock(&xs_state_lock);
>> + for (;;) {
>> + if (req->msg.tx_id != 0)
>> + break;
>> + if (xs_suspend_active) {
>> + spin_unlock(&xs_state_lock);
>> + wait_event(xs_state_enter_wq, xs_suspend_active == 0);
>> + spin_lock(&xs_state_lock);
>> + continue;
>> + }
>> + if (req->type == XS_TRANSACTION_START)
>> + xs_state_users++;
>> + break;
>> + }
>> + xs_state_users++;
>> + rq_id = xs_request_id++;
>> + spin_unlock(&xs_state_lock);
>> +
>> + return rq_id;
>> +}
>
> I should have noticed this last time but I've been looking at this code
> again and I don't think I understand why you are incrementing count for
> XS_TRANSACTION_START inside the loop.
>
> In fact, why not just 'while(xs_suspend_active) {}' loop?
That's a valid question.
I'll change it. The reason to have the larger loop body isn't existing
any longer.
Juergen
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web