xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 v8 for-xen-4.5 2/2] dpci: Replace tasklet with an softirq (v8)
Date: Mon, 27 Oct 2014 11:09:10 +0000	[thread overview]
Message-ID: <544E27D6.1040305@citrix.com> (raw)
In-Reply-To: <544E33B902000078000425F0@mail.emea.novell.com>

On 27/10/14 10:59, Jan Beulich wrote:
>>>> On 27.10.14 at 11:40, <andrew.cooper3@citrix.com> wrote:
>> The domctl lock is a hot lock, and looping with it held like this will
>> further starve other toolstack operations.
> The domctl lock normally shouldn't be a hot one. It only is if some tool
> stack component permanently issues domctl-s to obtain information on
> the state of the system. I think it wasn't so long ago that I said I
> consider this bad behavior of the tool stack...

Or there is a multi-threaded toolstack which is genuinely performing
legitimate toolstack operations on multiple domains.  This behaviour is
very easy to encounter with cloud workloads and automatic load
balancers.  This is not to say that Xapi could be less silly with some
of the operations it issues, but the global domctl lock is fundamentally
a bottleneck to parallel domain operations.

>
>> What is the likelihood that this loop will actually be used?  I am
>> guessing fairly rare, although it looks more likely to happen for an
>> interrupt which is firing frequently?
> I think it doesn't so much matter whether the loop will be used
> than how long it could end up spinning if used. And that shouldn't
> be long, considering that it only waits for interrupt handling to get
> finished.

Yes.  I don't disagree that this is probably the best way of handling
the situation, but it isn't 0-cost either.

Can it ever be the case that we are waiting for a remote pcpu to run its
softirq handler?  If so, the time spent looping here could be up to 1
scheduling timeslice in the worst case, and 30ms is a very long time to
wait.

~Andrew

  reply	other threads:[~2014-10-27 11:09 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21 17:19 [PATCH v8 for-xen-4.5] Fix interrupt latency of HVM PCI passthrough devices Konrad Rzeszutek Wilk
2014-10-21 17:19 ` [PATCH v8 for-xen-4.5 1/2] dpci: Move from an hvm_irq_dpci (and struct domain) to an hvm_dirq_dpci model Konrad Rzeszutek Wilk
2014-10-23  8:58   ` Jan Beulich
2014-10-24  1:58     ` Konrad Rzeszutek Wilk
2014-10-24  9:49       ` Jan Beulich
2014-10-24 19:09         ` Konrad Rzeszutek Wilk
2014-10-27  9:25           ` Jan Beulich
2014-10-27 16:36             ` Konrad Rzeszutek Wilk
2014-10-27 16:57               ` Jan Beulich
2014-10-21 17:19 ` [PATCH v8 for-xen-4.5 2/2] dpci: Replace tasklet with an softirq (v8) Konrad Rzeszutek Wilk
2014-10-23  9:36   ` Jan Beulich
2014-10-24  1:58     ` Konrad Rzeszutek Wilk
2014-10-24 10:09       ` Jan Beulich
2014-10-24 20:55         ` Konrad Rzeszutek Wilk
2014-10-25  0:39           ` Konrad Rzeszutek Wilk
2014-10-27  9:36             ` Jan Beulich
2014-10-27 16:36               ` Konrad Rzeszutek Wilk
2014-10-27  9:32           ` Jan Beulich
2014-10-27 10:40             ` Andrew Cooper
2014-10-27 10:59               ` Jan Beulich
2014-10-27 11:09                 ` Andrew Cooper [this message]
2014-10-27 11:24                   ` Jan Beulich
2014-10-27 17:01                     ` Konrad Rzeszutek Wilk
2014-10-27 17:36                       ` Andrew Cooper
2014-10-27 18:00                         ` Konrad Rzeszutek Wilk
2014-10-27 21:13                           ` Konrad Rzeszutek Wilk
2014-10-28 10:43                             ` Jan Beulich
2014-10-28 20:07                               ` Konrad Rzeszutek Wilk
2014-10-29  8:28                                 ` Jan Beulich
2014-10-29 21:11                                   ` Konrad Rzeszutek Wilk
2014-10-30  9:04                                     ` Jan Beulich
2014-11-02 20:09                                       ` Konrad Rzeszutek Wilk
2014-11-03  8:46                                         ` Jan Beulich
2014-10-28  7:58                         ` Jan Beulich
2014-10-28  7:53                       ` Jan Beulich

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=544E27D6.1040305@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=konrad.wilk@oracle.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).