From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, keir@xen.org,
ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org
Subject: Re: [PATCH v6 for-xen-4.5 3/3] dpci: Replace tasklet with an softirq (v6)
Date: Thu, 25 Sep 2014 11:27:22 -0400 [thread overview]
Message-ID: <20140925152722.GA24487@laptop.dumpdata.com> (raw)
In-Reply-To: <5424490002000078000390C5@mail.emea.novell.com>
On Thu, Sep 25, 2014 at 03:55:28PM +0100, Jan Beulich wrote:
> >>> On 23.09.14 at 04:10, <konrad.wilk@oracle.com> wrote:
> > +/*
> > + * If we are racing with softirq_dpci (masked is still set) we return
> > + * -EAGAIN. Otherwise we return 0.
> > + *
> > + * If it is -EAGAIN, it is the callers responsibility to kick the softirq
> > + * (with the event_lock dropped).
>
> But pt_pirq_cleanup_check() doesn't do this - is the comment
> misleading or that particular call site reacting wrongly? Actually the
> other call site doesn't kick any softirq either - what am I missing here?
The one call side that does is the 'pt_pirq_create..' which calls
'pt_pirq_reset'. The other ones:
a) domain_kill->domain_relinquish_resources->pci_release_devices->pci_clean_dpci_irq
b) pt_pirq_cleanup_check
are missing it. It is easy with a)- just add the process_pending_softirq()) in
when we are not holding the lock. But b) is much harder as we would need to
alter the whole 'pirq_cleanup_check' to return an error (as the callers of
'pirq_cleanup_check' are holding the lock) and perculate that up..
One way to do this is by ignoring the 'pt_pirq_cleanup_check' case as
the ramifications of that is that we would either re-use the 'pirq'
in pt_irq_create_bind or pick 'pirq' up at pci_clean_dpci_irq and then
remove it (and deal with the process_pending_softirq()).
That leaves a) case which is simple enough. I will add that in.
>
> > @@ -104,9 +148,20 @@ void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci)
> > *
> > * As such on every 'pt_irq_create_bind' call we MUST reset the values.
> > */
> > -static void pt_pirq_reset(struct domain *d, struct hvm_pirq_dpci *dpci)
> > +static int pt_pirq_reset(struct domain *d, struct hvm_pirq_dpci *dpci)
> > {
> > + /*
> > + * We MUST check for this condition as the softirq could be scheduled
> > + * and hasn't run yet. As such we MUST delay this reset until it has
> > + * completed its job.
> > + */
> > + if ( !pt_pirq_cleanup_check(dpci) )
> > + return -EAGAIN;
> > +
> > + INIT_LIST_HEAD(&dpci->softirq_list);
>
> What is this good for? This isn't a list head, and simple list elements
> don't need resetting of their link fields.
True. Left-over.
>
> > @@ -116,7 +171,9 @@ int pt_irq_create_bind(
> > struct hvm_pirq_dpci *pirq_dpci;
> > struct pirq *info;
> > int rc, pirq = pt_irq_bind->machine_irq;
> > + s_time_t start = NOW();
> >
> > + restart:
> > if ( pirq < 0 || pirq >= d->nr_pirqs )
> > return -EINVAL;
>
> I don't think this check needs re-doing on each restart.
OK.
>
> > @@ -146,7 +203,17 @@ int pt_irq_create_bind(
> > return -ENOMEM;
> > }
> > pirq_dpci = pirq_dpci(info);
> > - pt_pirq_reset(d, pirq_dpci);
> > + /* A crude 'while' loop with us dropping the spinlock and giving
> > + * the softirq_dpci a chance to run. We do this up to one second
> > + * at which point we give up. */
>
> Please fix the comment style, but ...
>
> > + if ( pt_pirq_reset(d, pirq_dpci) )
> > + {
> > + spin_unlock(&d->event_lock);
> > + process_pending_softirqs();
> > + if ( ( NOW() - start ) >> 30 )
> > + return -EAGAIN;
> > + goto restart;
> > + }
>
> ... this still looks more like a hack, and I'm still not really certain
> why between two uses (which is what I understand this is for) the
> pIRQ (and hence it's softirq instance) won't be fully quiesced.
Just to make it clear - the 'pirq_guest_unbind' (which is called in the
pt_irq_destroy_bind) will take care of removing the action. So no more
__do_IRQ calls using the 'pirq' after that.
But we might have a pending softirq after we finished with pt_irq_destroy_bind.
And this loop will take care of waiting it out. This problem had
existed prior to this patch - this wait loop was done inside the 'tasklet_kill'.
I added the 1 second timeout as I am not a fan of unbound loops. But
I can put it back in to make it simpler (and look less hacky).
>
> > +static void dpci_softirq(void)
> > +{
> > + struct hvm_pirq_dpci *pirq_dpci;
> > + unsigned int cpu = smp_processor_id();
> > + LIST_HEAD(our_list);
> > +
> > + local_irq_disable();
> > + list_splice_init(&per_cpu(dpci_list, cpu), &our_list);
> > + local_irq_enable();
> > +
> > + while ( !list_empty(&our_list) )
> > + {
> > + pirq_dpci = list_entry(our_list.next, struct hvm_pirq_dpci, softirq_list);
> > + list_del(&pirq_dpci->softirq_list);
> > +
> > + hvm_dirq_assist(pirq_dpci);
> > +
> > + put_domain(pirq_dpci->dom);
> > + pirq_dpci->masked = 0;
> > + }
> > +}
> > +static int cpu_callback(
>
> There is again/still a blank line missing here.
Grrr.
Thank you again for your excellent review!
>
> Jan
>
next prev parent reply other threads:[~2014-09-25 15:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-23 2:10 [PATCH v6] Fix interrupt latency of HVM PCI passthrough devices Konrad Rzeszutek Wilk
2014-09-23 2:10 ` [PATCH v6 for-xen-4.5 1/3] dpci: Move from domain centric model to hvm_dirq_dpci model Konrad Rzeszutek Wilk
2014-09-25 14:24 ` Jan Beulich
2014-09-25 14:48 ` Konrad Rzeszutek Wilk
2014-09-25 15:04 ` Jan Beulich
2014-09-27 1:32 ` Konrad Rzeszutek Wilk
2014-09-29 7:21 ` Jan Beulich
2014-10-07 15:40 ` Konrad Rzeszutek Wilk
2014-10-07 16:10 ` Jan Beulich
2014-09-23 2:10 ` [PATCH v6 for-xen-4.5 2/3] dpci: In hvm_dirq_assist stop using pt_pirq_iterate Konrad Rzeszutek Wilk
2014-09-25 14:29 ` Jan Beulich
2014-09-23 2:10 ` [PATCH v6 for-xen-4.5 3/3] dpci: Replace tasklet with an softirq (v6) Konrad Rzeszutek Wilk
2014-09-25 14:55 ` Jan Beulich
2014-09-25 15:27 ` Konrad Rzeszutek Wilk [this message]
2014-09-25 15:45 ` Jan Beulich
2014-09-25 16:05 ` Konrad Rzeszutek Wilk
2014-09-27 1:32 ` Konrad Rzeszutek Wilk
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=20140925152722.GA24487@laptop.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=keir@xen.org \
--cc=tim@xen.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.