From: David Vrabel <david.vrabel@citrix.com>
To: Andy Lutomirski <luto@amacapital.net>,
David Vrabel <david.vrabel@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
"Luis R. Rodriguez" <mcgrof@suse.com>
Subject: Re: [PATCHv5] x86/xen: allow privcmd hypercalls to be preempted
Date: Fri, 6 Feb 2015 10:01:18 +0000 [thread overview]
Message-ID: <54D490EE.3000504@citrix.com> (raw)
In-Reply-To: <CALCETrVVfYnKN3FTmLekLFTfDf7BVrh-tatQMSOR-+xjxk0QPQ@mail.gmail.com>
On 06/02/15 00:50, Andy Lutomirski wrote:
> On Thu, Feb 5, 2015 at 4:41 AM, David Vrabel <david.vrabel@citrix.com> wrote:
>> Hypercalls submitted by user space tools via the privcmd driver can
>> take a long time (potentially many 10s of seconds) if the hypercall
>> has many sub-operations.
>>
>
>> +
>> +void xen_maybe_preempt_hcall(void)
>
> I think this should be asmlinkage __visible. Other than that, this
> looks good to me. I like your solution to the tracking problem.
>
>> +{
>> + if (__this_cpu_read(xen_in_preemptible_hcall)) {
>
> Hmm. That being said, is there any issue with nested interrupts?
The should_resched() check in _cond_resched() already handles this
because irq_enter() sets the preempt count as non-zero.
FWIW, XenServer has been using something like this in production for
about a year without any problems.
David
prev parent reply other threads:[~2015-02-06 10:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 12:41 [PATCHv5] x86/xen: allow privcmd hypercalls to be preempted David Vrabel
2015-02-05 15:37 ` Boris Ostrovsky
2015-02-05 15:39 ` David Vrabel
2015-02-05 16:11 ` Boris Ostrovsky
2015-02-05 16:14 ` David Vrabel
2015-02-05 16:16 ` Boris Ostrovsky
2015-02-05 18:14 ` Luis R. Rodriguez
2015-02-05 18:23 ` Andrew Cooper
2015-02-05 18:36 ` Luis R. Rodriguez
2015-02-06 0:50 ` Andy Lutomirski
2015-02-06 10:01 ` David Vrabel [this message]
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=54D490EE.3000504@citrix.com \
--to=david.vrabel@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=luto@amacapital.net \
--cc=mcgrof@suse.com \
--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.