From: David Vrabel <david.vrabel@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Keir Fraser <keir@xen.org>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 0/2] make hypercall preemption checks consistent
Date: Tue, 4 Mar 2014 14:07:50 +0000 [thread overview]
Message-ID: <5315DE36.5070705@citrix.com> (raw)
In-Reply-To: <5315DDDD0200007800120DDF@nat28.tlf.novell.com>
On 04/03/14 13:06, Jan Beulich wrote:
>>>> On 04.03.14 at 13:10, David Vrabel <david.vrabel@citrix.com> wrote:
>> On 04/03/14 12:00, Jan Beulich wrote:
>>>>>> On 04.03.14 at 12:52, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> On 04/03/14 11:21, Jan Beulich wrote:
>>>>> - never preempt on the first iteration (ensure forward progress)
>>>>> - never preempt on the last iteration (pointless/wasteful)
>>>>> - do cheap checks first
>>>>>
>>>>> 1: common: make hypercall preemption checks consistent
>>>>> 2: x86: make hypercall preemption checks consistent
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>
>>>> All in all, this is a good improvement over what is currently present.
>>>>
>>>> However, given the overhead of creating continuations (particularly for
>>>> 32bit HVM guests, which have been seen to unconditionally fail the
>>>> preemption check by the time the compat layer has run), some of these
>>>> operations would probably be better having more than a single guaranteed
>>>> operation.
>>>
>>> I agree, but I wanted to do one step at a time. Judging how much
>>> work we want to permit done between preemption points will be
>>> either heavy guess work, or require quite a bit of performance
>>> measurement...
>>
>> Perhaps something time-based? Record the time at start and make
>> hypercall_preempt_check() return true if more than T time has elapsed?
>
> That's certainly an interesting idea. But it doesn't remove the need
> to determine the actual value of the parameter to use (T in this case).
Sure, but it should be just one parameter for all hypercalls instead of
having to consider each one separately.
David
next prev parent reply other threads:[~2014-03-04 14:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 11:21 [PATCH 0/2] make hypercall preemption checks consistent Jan Beulich
2014-03-04 11:24 ` [PATCH 1/2] common: " Jan Beulich
2014-03-04 11:29 ` Andrew Cooper
2014-03-04 11:26 ` [PATCH 2/2] x86: " Jan Beulich
2014-03-04 11:35 ` Andrew Cooper
2014-03-04 11:30 ` [PATCH 0/2] " Jan Beulich
2014-03-11 11:38 ` Ian Campbell
2014-03-04 11:46 ` Tim Deegan
2014-03-04 11:52 ` Andrew Cooper
2014-03-04 12:00 ` Jan Beulich
2014-03-04 12:10 ` David Vrabel
2014-03-04 13:06 ` Jan Beulich
2014-03-04 14:07 ` David Vrabel [this message]
2014-03-12 9:35 ` Ping: " Jan Beulich
2014-03-13 10:26 ` Keir Fraser
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=5315DE36.5070705@citrix.com \
--to=david.vrabel@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=keir@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).