From: Steven Rostedt <rostedt@goodmis.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: "Marciniszyn, Mike" <mike.marciniszyn@intel.com>,
"Dalessandro, Dennis" <dennis.dalessandro@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Clark Williams <williams@redhat.com>,
"Luick, Dean" <dean.luick@intel.com>,
Doug Ledford <dledford@redhat.com>,
"Wan, Kaike" <kaike.wan@intel.com>,
Leon Romanovsky <leonro@mellanox.com>,
Peter Zijlstra <peterz@infradead.org>,
Sebastian Andrzej Siewior <sebastian.siewior@linutronix.de>,
"Sanchez, Sebastian" <sebastian.sanchez@intel.com>,
"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: [RFC+PATCH] Infiniband hfi1 + PREEMPT_RT_FULL issues
Date: Tue, 26 Sep 2017 17:11:56 -0400 [thread overview]
Message-ID: <20170926171156.6f7e3b4b@vmware.local.home> (raw)
In-Reply-To: <20170926182800.GA10741@kernel.org>
On Tue, 26 Sep 2017 15:28:00 -0300
Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> So what happens is that infrastructure in the rt patch eventually lands
> upstream, then this difference ceases to exist.
>
> Steven, are there plans for local locks to go upstream?
>
Yes, but they don't make sense unless we get PREEMPT_RT (sleeping
spinlocks) upstream. Otherwise, they will just be another name for
preempt_disable().
That said, there is some rational for getting them upsteam before
sleeping spinlocks, and that is to annotate what a preempt_disable() is
trying to protect.
-- Steve
next prev parent reply other threads:[~2017-09-26 21:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-25 14:49 [RFC+PATCH] Infiniband hfi1 + PREEMPT_RT_FULL issues Arnaldo Carvalho de Melo
2017-09-25 19:45 ` Arnaldo Carvalho de Melo
[not found] ` <20170925144949.GP29668-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-09-25 20:15 ` Steven Rostedt
[not found] ` <20170925161528.52d34769-ZM9ACYiE99GSuEeoRQArULNAH6kLmebB@public.gmane.org>
2017-09-26 13:15 ` Arnaldo Carvalho de Melo
[not found] ` <20170926131529.GB25735-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-09-26 17:55 ` Marciniszyn, Mike
2017-09-26 18:28 ` Arnaldo Carvalho de Melo
2017-09-26 21:11 ` Steven Rostedt [this message]
2017-09-25 21:14 ` Julia Cartwright
2017-09-26 14:10 ` Marciniszyn, Mike
[not found] ` <32E1700B9017364D9B60AED9960492BC3441B3BD-RjuIdWtd+YbTXloPLtfHfbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2017-09-26 14:56 ` Steven Rostedt
2017-09-26 21:00 ` Julia Cartwright
2017-10-06 9:23 ` Sebastian Andrzej Siewior
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=20170926171156.6f7e3b4b@vmware.local.home \
--to=rostedt@goodmis.org \
--cc=acme@kernel.org \
--cc=dean.luick@intel.com \
--cc=dennis.dalessandro@intel.com \
--cc=dledford@redhat.com \
--cc=kaike.wan@intel.com \
--cc=leonro@mellanox.com \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=mike.marciniszyn@intel.com \
--cc=peterz@infradead.org \
--cc=sebastian.sanchez@intel.com \
--cc=sebastian.siewior@linutronix.de \
--cc=tglx@linutronix.de \
--cc=williams@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox