All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Keir Fraser <keir@xen.org>
Cc: Malcolm Crossley <malcolm.crossley@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v2 1/2] x86: defer processing events on the NMI exit path
Date: Fri, 1 Mar 2013 16:01:17 +0000	[thread overview]
Message-ID: <5130D0CD.9090305@citrix.com> (raw)
In-Reply-To: <CD568020.5D214%keir@xen.org>

On 01/03/13 15:56, Keir Fraser wrote:
> On 01/03/2013 11:53, "Jan Beulich" <JBeulich@suse.com> wrote:
>
>>> __softirq_pending is an unsigned long.  Would it not be prudent to use
>>> cmpq to save obscure bugs if the implementation changes, or are we
>>> sufficiently sure that this wont happen?
>> All other existing instances of similar assembly code use testl or
>> cmpl, and in fact I merely copied some other instance.
>>
>> As we're not getting close to 32, I think we might rather want to
>> adjust the __softirq_pending type. Keir?
> Yup, I don't see any reason why it couldn't be a uint32_t.
>
>  -- Keir
>
>

Further to that, is there any reason that it cant be per-cpu, to save
having information like this moving around pcpus in a hot cache line?

~Andrew

  reply	other threads:[~2013-03-01 16:01 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-22 15:00 [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT handler Andrew Cooper
2012-11-22 15:15 ` Jan Beulich
2012-11-22 15:16   ` Andrew Cooper
2012-11-22 15:21     ` Jan Beulich
2012-11-22 15:37       ` Andrew Cooper
2012-11-22 15:55         ` Jan Beulich
2012-11-22 16:05           ` Andrew Cooper
2012-11-22 16:12             ` Jan Beulich
2012-11-22 16:31               ` Andrew Cooper
2013-02-28  9:58             ` Jan Beulich
2013-02-28 12:32               ` Andrew Cooper
2013-02-28 13:00               ` Tim Deegan
2013-02-28 13:12                 ` Andrew Cooper
2013-02-28 13:39                 ` Jan Beulich
2013-02-28 14:25                   ` Tim Deegan
2013-02-28 14:42                     ` Jan Beulich
2013-02-28 14:45                       ` Andrew Cooper
2013-02-28 14:49                       ` Tim Deegan
2013-02-28 15:01                         ` Jan Beulich
2013-02-28 15:41                       ` Jan Beulich
2013-02-28 15:52                         ` Andrew Cooper
2013-02-28 15:55                         ` Tim Deegan
2013-02-28 16:12                           ` Jan Beulich
2013-02-28 16:01                         ` Keir Fraser
2013-02-28 16:17                           ` Jan Beulich
2013-02-28 19:02                             ` Keir Fraser
2013-03-01 10:49                               ` [PATCH v2 0/2] x86: defer processing events on the NMI exit path Jan Beulich
2013-03-01 10:56                                 ` [PATCH v2 1/2] " Jan Beulich
2013-03-01 11:37                                   ` Andrew Cooper
2013-03-01 11:53                                     ` Jan Beulich
2013-03-01 15:56                                       ` Keir Fraser
2013-03-01 16:01                                         ` Andrew Cooper [this message]
2013-03-01 16:08                                           ` Jan Beulich
2013-03-01 10:57                                 ` [PATCH v2 2/2] x86: don't rely on __softirq_pending to be the first field in irq_cpustat_t Jan Beulich
2013-03-01 15:55                                 ` [PATCH v2 0/2] x86: defer processing events on the NMI exit path Keir Fraser
2013-02-28 13:42                 ` [PATCH V3] vmx/nmi: Do not use self_nmi() in VMEXIT handler Jan Beulich
2013-02-28 14:04                   ` Tim Deegan
2013-02-28 14:51                 ` Konrad Rzeszutek Wilk
2012-11-22 15:22     ` Mats Petersson
2012-11-22 16:00       ` Jan Beulich
2012-11-22 17:34 ` Tim Deegan
2012-11-26 11:50   ` George Dunlap

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=5130D0CD.9090305@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=malcolm.crossley@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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.