From: Scott Wood <scottwood@freescale.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-rt-users@vger.kernel.org, Alexander Graf <agraf@suse.de>,
linux-kernel@vger.kernel.org,
Bogdan Purcareata <bogdan.purcareata@freescale.com>,
mihai.caraman@freescale.com, Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux
Date: Thu, 26 Feb 2015 19:05:59 -0600 [thread overview]
Message-ID: <1424999159.4698.78.camel@freescale.com> (raw)
In-Reply-To: <54EF2025.80404@linutronix.de>
On Thu, 2015-02-26 at 14:31 +0100, Sebastian Andrzej Siewior wrote:
> On 02/26/2015 02:02 PM, Paolo Bonzini wrote:
> >
> >
> > On 24/02/2015 00:27, Scott Wood wrote:
> >> This isn't a host PIC driver. It's guest PIC emulation, some of which
> >> is indeed not suitable for a rawlock (in particular, openpic_update_irq
> >> which loops on the number of vcpus, with a loop body that calls
> >> IRQ_check() which loops over all pending IRQs).
> >
> > The question is what behavior is wanted of code that isn't quite
> > RT-ready. What is preferred, bugs or bad latency?
> >
> > If the answer is bad latency (which can be avoided simply by not running
> > KVM on a RT kernel in production), patch 1 can be applied. If the
> can be applied *but* makes no difference if applied or not.
>
> > answer is bugs, patch 1 is not upstream material.
> >
> > I myself prefer to have bad latency; if something takes a spinlock in
> > atomic context, that spinlock should be raw. If it hurts (latency),
> > don't do it (use the affected code).
>
> The problem, that is fixed by this s/spin_lock/raw_spin_lock/, exists
> only in -RT. There is no change upstream. In general we fix such things
> in -RT first and forward the patches upstream if possible. This convert
> thingy would be possible.
> Bug fixing comes before latency no matter if RT or not. Converting
> every lock into a rawlock is not always the answer.
> Last thing I read from Scott is that he is not entirely sure if this is
> the right approach or not and patch #1 was not acked-by him either.
>
> So for now I wait for Scott's feedback and maybe a backtrace :)
Obviously leaving it in a buggy state is not what we want -- but I lean
towards a short term "fix" of putting "depends on !PREEMPT_RT" on the
in-kernel MPIC emulation (which is itself just an optimization -- you
can still use KVM without it). This way people don't enable it with RT
without being aware of the issue, and there's more of an incentive to
fix it properly.
I'll let Bogdan supply the backtrace.
-Scott
next prev parent reply other threads:[~2015-02-27 1:06 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-18 9:32 [PATCH 0/2] powerpc/kvm: Enable running guests on RT Linux Bogdan Purcareata
2015-02-18 9:32 ` [PATCH 1/2] powerpc/kvm: Convert openpic lock to raw_spinlock Bogdan Purcareata
2015-02-23 22:43 ` Scott Wood
2015-02-18 9:32 ` [PATCH 2/2] powerpc/kvm: Limit MAX_VCPUS for guests running on RT Linux Bogdan Purcareata
2015-02-18 9:36 ` Sebastian Andrzej Siewior
2015-02-20 13:45 ` Alexander Graf
2015-02-23 22:48 ` Scott Wood
2015-02-20 13:45 ` [PATCH 0/2] powerpc/kvm: Enable running guests " Alexander Graf
2015-02-20 14:12 ` Paolo Bonzini
2015-02-20 14:16 ` Alexander Graf
2015-02-20 14:54 ` Sebastian Andrzej Siewior
2015-02-20 14:57 ` Paolo Bonzini
2015-02-20 15:06 ` Sebastian Andrzej Siewior
2015-02-20 15:10 ` Paolo Bonzini
2015-02-20 15:17 ` Sebastian Andrzej Siewior
2015-02-23 8:12 ` Purcareata Bogdan
2015-02-23 7:50 ` Purcareata Bogdan
2015-02-23 7:29 ` Purcareata Bogdan
2015-02-23 23:27 ` Scott Wood
2015-02-25 16:36 ` Sebastian Andrzej Siewior
2015-02-26 13:02 ` Paolo Bonzini
2015-02-26 13:31 ` Sebastian Andrzej Siewior
2015-02-27 1:05 ` Scott Wood [this message]
2015-02-27 13:06 ` Paolo Bonzini
2015-03-27 17:07 ` Purcareata Bogdan
2015-04-02 23:11 ` Scott Wood
2015-04-03 8:07 ` Purcareata Bogdan
2015-04-03 21:26 ` Scott Wood
2015-04-09 7:44 ` Purcareata Bogdan
2015-04-09 23:53 ` Scott Wood
2015-04-20 10:53 ` Purcareata Bogdan
2015-04-21 0:52 ` Scott Wood
2015-04-22 12:06 ` Purcareata Bogdan
2015-04-23 0:30 ` Scott Wood
2015-04-23 12:31 ` Purcareata Bogdan
2015-04-23 21:26 ` Scott Wood
2015-04-27 6:45 ` Purcareata Bogdan
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=1424999159.4698.78.camel@freescale.com \
--to=scottwood@freescale.com \
--cc=agraf@suse.de \
--cc=bigeasy@linutronix.de \
--cc=bogdan.purcareata@freescale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mihai.caraman@freescale.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
/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).