All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: <linux-kernel@vger.kernel.org>, <xen-devel@lists.xensource.com>,
	Keir Fraser <keir.fraser@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/evtchn: Handle VIRQ_TIMER before any other hardirq in event loop.
Date: Tue, 2 Apr 2013 15:53:13 +0100	[thread overview]
Message-ID: <515AF0D9.80805@citrix.com> (raw)
In-Reply-To: <1364825261-25324-1-git-send-email-konrad.wilk@oracle.com>

On 01/04/13 15:07, Konrad Rzeszutek Wilk wrote:
> From: Keir Fraser <keir.fraser@citrix.com>
> 
> This avoids any other hardirq handler seeing a very stale jiffies
> value immediately after wakeup from a long idle period. The one
> observable symptom of this was a USB keyboard, with software keyboard
> repeat, which would always repeat a key immediately that it was
> pressed. This is due to the key press waking the guest, the key
> handler immediately runs, sees an old jiffies value, and then that
> jiffies value significantly updated, before the key is unpressed.

It's a bit of hack but what else can you do when there is no generic
mechanism to have different event priorities.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

The subject should be prefixed with: "xen/events" as this isn't a patch
to the evtchn driver.

David

WARNING: multiple messages have this Message-ID (diff)
From: David Vrabel <david.vrabel@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
	Keir Fraser <keir.fraser@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen/evtchn: Handle VIRQ_TIMER before any other hardirq in event loop.
Date: Tue, 2 Apr 2013 15:53:13 +0100	[thread overview]
Message-ID: <515AF0D9.80805@citrix.com> (raw)
In-Reply-To: <1364825261-25324-1-git-send-email-konrad.wilk@oracle.com>

On 01/04/13 15:07, Konrad Rzeszutek Wilk wrote:
> From: Keir Fraser <keir.fraser@citrix.com>
> 
> This avoids any other hardirq handler seeing a very stale jiffies
> value immediately after wakeup from a long idle period. The one
> observable symptom of this was a USB keyboard, with software keyboard
> repeat, which would always repeat a key immediately that it was
> pressed. This is due to the key press waking the guest, the key
> handler immediately runs, sees an old jiffies value, and then that
> jiffies value significantly updated, before the key is unpressed.

It's a bit of hack but what else can you do when there is no generic
mechanism to have different event priorities.

Reviewed-by: David Vrabel <david.vrabel@citrix.com>

The subject should be prefixed with: "xen/events" as this isn't a patch
to the evtchn driver.

David

  reply	other threads:[~2013-04-02 14:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-01 14:07 [PATCH] xen/evtchn: Handle VIRQ_TIMER before any other hardirq in event loop Konrad Rzeszutek Wilk
2013-04-02 14:53 ` David Vrabel [this message]
2013-04-02 14:53   ` [Xen-devel] " David Vrabel

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=515AF0D9.80805@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=keir.fraser@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /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.