All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xen.org
Subject: Re: [PATCH 16/16] xen/events: use the FIFO-based ABI if available
Date: Wed, 16 Oct 2013 09:26:43 -0400	[thread overview]
Message-ID: <525E9413.70907@oracle.com> (raw)
In-Reply-To: <525E607D.8040900@citrix.com>

On 10/16/2013 05:46 AM, David Vrabel wrote:
> On 15/10/13 21:39, Boris Ostrovsky wrote:
>> On 10/15/2013 02:58 PM, David Vrabel wrote:
>>> On 14/10/13 20:30, Boris Ostrovsky wrote:
>>>> On 10/08/2013 08:49 AM, David Vrabel wrote:
>>>>> @@ -1636,7 +1637,13 @@ void xen_callback_vector(void) {}
>>>>>       void __init xen_init_IRQ(void)
>>>>>     {
>>>>> -    xen_evtchn_2l_init();
>>>>> +    int ret;
>>>>> +
>>>>> +    ret = xen_evtchn_fifo_init();
>>>>> +    if (ret < 0) {
>>>>> +        printk(KERN_INFO "xen: falling back to n-level event
>>>>> channels");
>>>>> +        xen_evtchn_2l_init();
>>>>> +    }
>>>> Should we provide users with ability to choose which mechanism to use?
>>>> Is there any advantage in staying with 2-level? Stability, I guess,
>>>> would be one.
>>> If someone can demonstrate a use case where 2-level is better then we
>>> could consider an option.  I don't think we want options for new
>>> software features just because they might be buggy.
>> I think we should always try to have a way to force old behavior when a
>> new feature is introduced. If a user discovers a bug we don't want them
>> to wait for a fix when a simpler solution is possible. I can see that
>> having this option in the kernel may be a bit too much but is there at
>> least an option to force 2-level in the hypervisor?
> The majority of the risk in this series is the refactoring patches and
> not the new ABI code so an option to disable it wouldn't really help.
>
> Also, if we are not confidant that a feature is production ready that we
> need knobs to turn it off then we shouldn't merge it.

I disagree. If this were the case then hardware wouldn't have chicken 
bits and there wouldn't exist half of "no*" options to kernel, for example.

We are introducing a rewrite of a critical component of the system. It 
has bugs (by definition) and there should be a way to fall back to an 
implementation that presumably has fewer bugs.

-boris

  reply	other threads:[~2013-10-16 13:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-08 12:48 [PATCHv6 00/16] Linux: FIFO-based event channel ABI David Vrabel
2013-10-08 12:49 ` [PATCH 01/16] xen/events: refactor retrigger_dynirq() and resend_irq_on_evtchn() David Vrabel
2013-10-14 15:59   ` Boris Ostrovsky
2013-10-14 16:35     ` David Vrabel
2013-10-08 12:49 ` [PATCH 02/16] xen/events: remove unnecessary init_evtchn_cpu_bindings() David Vrabel
2013-10-08 12:49 ` [PATCH 03/16] xen/events: introduce test_and_set_mask David Vrabel
2013-10-08 12:49 ` [PATCH 04/16] xen/events: replace raw bit ops with functions David Vrabel
2013-10-14 16:30   ` Boris Ostrovsky
2013-10-14 16:43     ` David Vrabel
2013-10-08 12:49 ` [PATCH 05/16] xen/events: move drivers/xen/events.c into drivers/xen/events/ David Vrabel
2013-10-08 12:49 ` [PATCH 06/16] xen/events: move 2-level specific code into its own file David Vrabel
2013-10-14 16:50   ` Boris Ostrovsky
2013-10-14 16:53     ` David Vrabel
2013-10-08 12:49 ` [PATCH 07/16] xen/events: add struct evtchn_ops for the low-level port operations David Vrabel
2013-10-08 12:49 ` [PATCH 08/16] xen/events: allow setup of irq_info to fail David Vrabel
2013-10-14 17:26   ` Boris Ostrovsky
2013-10-15 19:20     ` David Vrabel
2013-10-08 12:49 ` [PATCH 09/16] xen/events: add a evtchn_op for port setup David Vrabel
2013-10-08 12:49 ` [PATCH 10/16] xen/events: Refactor evtchn_to_irq array to be dynamically allocated David Vrabel
2013-10-14 17:52   ` Boris Ostrovsky
2013-10-15 18:58     ` David Vrabel
2013-10-08 12:49 ` [PATCH 11/16] xen/events: add xen_evtchn_mask_all() David Vrabel
2013-10-08 12:49 ` [PATCH 12/16] xen/evtchn: support more than 4096 ports David Vrabel
2013-10-14 18:06   ` Boris Ostrovsky
2013-10-08 12:49 ` [PATCH 13/16] xen/events: Add the hypervisor interface for the FIFO-based event channels David Vrabel
2013-10-08 12:49 ` [PATCH 14/16] xen/events: allow event channel priority to be set David Vrabel
2013-10-08 12:49 ` [PATCH 15/16] xen/x86: set VIRQ_TIMER priority to maximum David Vrabel
2013-10-08 12:49 ` [PATCH 16/16] xen/events: use the FIFO-based ABI if available David Vrabel
2013-10-14 19:30   ` Boris Ostrovsky
2013-10-15 18:58     ` David Vrabel
2013-10-15 20:39       ` Boris Ostrovsky
2013-10-16  9:46         ` David Vrabel
2013-10-16 13:26           ` Boris Ostrovsky [this message]
2013-10-16 13:49             ` David Vrabel
2013-10-14 13:41 ` [PATCHv6 00/16] Linux: FIFO-based event channel ABI David Vrabel
2013-10-16 15:19   ` Ian Campbell
2013-10-16 15:36     ` David Vrabel
2013-10-16 15:38     ` Ian Jackson
  -- strict thread matches above, loose matches on Subject: below --
2013-11-11 16:12 [PATCHv9 " David Vrabel
2013-11-11 16:13 ` [PATCH 16/16] xen/events: use the FIFO-based ABI if available David Vrabel
2013-10-31 15:09 [PATCHv8 00/16] Linux: FIFO-based event channel ABI David Vrabel
2013-10-31 15:09 ` [PATCH 16/16] xen/events: use the FIFO-based ABI if available David Vrabel
2013-10-18 14:23 [PATCHv7 00/16] Linux: FIFO-based event channel ABI David Vrabel
2013-10-18 14:23 ` [PATCH 16/16] xen/events: use the FIFO-based ABI if available David Vrabel
2013-10-02 17:14 [PATCHv5 00/16] Linux: FIFO-based event channel ABI David Vrabel
2013-10-02 17:15 ` [PATCH 16/16] xen/events: use the FIFO-based ABI if available 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=525E9413.70907@oracle.com \
    --to=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jbeulich@suse.com \
    --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.