From: Steven Rostedt <rostedt@goodmis.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Julia Cartwright <julia@ni.com>,
	bigeasy@linutronix.de, linux-rt-users@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Clark Williams <williams@redhat.com>,
	Dean Luick <dean.luick@intel.com>,
	Dennis Dalessandro <dennis.dalessandro@intel.com>,
	Doug Ledford <dledford@redhat.com>,
	Kaike Wan <kaike.wan@intel.com>,
	Leon Romanovsky <leonro@mellanox.com>,
	linux-rdma@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Sebastian Andrzej Siewior <sebastian.siewior@linutronix.de>,
	Sebastian Sanchez <sebastian.sanchez@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"Marciniszyn, Mike" <mike.marciniszyn@intel.com>
Subject: Re: [PATCH 1/2] IB/hfi1: Use preempt_{dis,en}able_nort()
Date: Thu, 5 Oct 2017 15:15:17 -0400	[thread overview]
Message-ID: <20171005151517.0c948504@gandalf.local.home> (raw)
In-Reply-To: <20171005185330.GP25388@kernel.org>
On Thu, 5 Oct 2017 15:53:30 -0300
Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Em Thu, Oct 05, 2017 at 01:29:00PM -0500, Julia Cartwright escreveu:
> > On Thu, Oct 05, 2017 at 01:53:05PM -0300, Arnaldo Carvalho de Melo wrote:  
> > > So __this_cpu_inc() checks preemption but this_cpu_inc() doesn't and
> > > thus we're ok here? Or am I getting lost in this maze of defines? :-)  
>  
> > I think I was the one lost in the maze.  You are correct.  Sorry for the
> > confusion.  
>  
> > My mind expected that the __ prefixed versions would be the "raw"
> > versions that are free of checks, with the checks made in the non
> > prefixed versions, but it is the other way around.  
>  
> > I'm happy to accept that the bug is within my mind.  
> 
> :-) 
> 
> Ok, now I'm taking the opportunity to read more about local locks, as
> Sebastian thinks are needed in this case, which I'm not entirely
> convinced from the discussion that took place here, and as you took part
> in that discussion and suggested using the nort variants of
> preempt_disable, do you still think this is the way to go?
>
Looking at
http://lkml.kernel.org/r/32E1700B9017364D9B60AED9960492BC3441B3BD@fmsmsx120.amr.corp.intel.com
I'm thinking it is fine to convert the preempt_disable() just to
preempt_disable_nort() (where it's a nop when PREEMPT_RT is enabled).
In the mentioned thread, the counters do not seem to be important to
the current CPU, just that they get incremented by "some" CPU.
Adding back the patch for Mike:
diff --git a/drivers/infiniband/hw/hfi1/pio.c b/drivers/infiniband/hw/hfi1/pio.c
index 615be68e40b3..3a30bde9a07b 100644
--- a/drivers/infiniband/hw/hfi1/pio.c
+++ b/drivers/infiniband/hw/hfi1/pio.c
@@ -1421,7 +1421,7 @@ struct pio_buf *sc_buffer_alloc(struct send_context *sc, u32 dw_len,
 
 	/* there is enough room */
 
-	preempt_disable();
+	preempt_disable_nort();
 	this_cpu_inc(*sc->buffers_allocated);
 
 	/* read this once */
diff --git a/drivers/infiniband/hw/hfi1/pio_copy.c b/drivers/infiniband/hw/hfi1/pio_copy.c
index 03024cec78dd..c3f48f705c97 100644
--- a/drivers/infiniband/hw/hfi1/pio_copy.c
+++ b/drivers/infiniband/hw/hfi1/pio_copy.c
@@ -162,7 +162,7 @@ void pio_copy(struct hfi1_devdata *dd, struct pio_buf *pbuf, u64 pbc,
 
 	/* finished with this buffer */
 	this_cpu_dec(*pbuf->sc->buffers_allocated);
-	preempt_enable();
+	preempt_enable_nort();
 }
 
 /*
@@ -753,5 +753,5 @@ void seg_pio_copy_end(struct pio_buf *pbuf)
 
 	/* finished with this buffer */
 	this_cpu_dec(*pbuf->sc->buffers_allocated);
-	preempt_enable();
+	preempt_enable_nort();
 }
The above will only disable preemption when PREEMPT_RT is not enabled.
Honestly, if it's just an optimization, and the counters are not that
important, do we care on non PREEMPT_RT to disable preemption, and can
we just remove the preempt_disable() totally? Depending if it triggers
warnings using this_cpu_inc/dec() from preempt enabled regions.
-- Steve
next prev parent reply	other threads:[~2017-10-05 19:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03 15:49 [GIT PULL 0/2] infiniband hfi1 PREEMPT_RT_FULL changes Arnaldo Carvalho de Melo
2017-10-03 15:49 ` [PATCH 1/2] IB/hfi1: Use preempt_{dis,en}able_nort() Arnaldo Carvalho de Melo
2017-10-05 14:17   ` Julia Cartwright
     [not found]     ` <20171005141744.GC21185-ew3lsbMjNqt5wtABiV/Xjqyly8cj88Ttqxv4g6HH51o@public.gmane.org>
2017-10-05 15:27       ` Thomas Gleixner
2017-10-05 15:37         ` Julia Cartwright
     [not found]           ` <20171005153759.GG647-ew3lsbMjNqt5wtABiV/Xjqyly8cj88Ttqxv4g6HH51o@public.gmane.org>
2017-10-05 15:55             ` Steven Rostedt
2017-10-05 16:05               ` Julia Cartwright
2017-10-05 16:16                 ` Thomas Gleixner
2017-10-05 16:39                   ` Julia Cartwright
2017-10-05 16:53       ` Arnaldo Carvalho de Melo
2017-10-05 18:29         ` Julia Cartwright
     [not found]           ` <20171005182900.GK647-ew3lsbMjNqt5wtABiV/Xjqyly8cj88Ttqxv4g6HH51o@public.gmane.org>
2017-10-05 18:53             ` Arnaldo Carvalho de Melo
2017-10-05 19:15               ` Steven Rostedt [this message]
2017-10-05 16:30   ` Sebastian Andrzej Siewior
2017-10-06  9:19     ` Sebastian Andrzej Siewior
     [not found]   ` <20171003154920.31566-2-acme-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-10-10 18:59     ` Dennis Dalessandro
     [not found]       ` <1d06a3da-426f-c887-1da7-64b760c53425-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-10-10 19:02         ` Arnaldo Carvalho de Melo
     [not found]           ` <20171010190218.GN28623-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-10-11 11:03             ` Sebastian Andrzej Siewior
2017-10-11 13:43               ` Arnaldo Carvalho de Melo
2017-10-03 15:49 ` [PATCH 2/2] IB/hfi1: Handle packets in the theaded handler only Arnaldo Carvalho de Melo
2017-10-05 16:27   ` Sebastian Andrzej Siewior
2017-10-10 19:06   ` Dennis Dalessandro
2017-10-10 19:15     ` Arnaldo Carvalho de Melo
2017-10-11 10:44       ` Sebastian Andrzej Siewior
2017-10-11 13:42         ` Arnaldo Carvalho de Melo
     [not found]         ` <20171011104456.mlewocqc6ghi3fev-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2017-10-11 19:07           ` Arnaldo Carvalho de Melo
2017-10-11 19:14             ` Arnaldo Carvalho de Melo
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=20171005151517.0c948504@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=dean.luick@intel.com \
    --cc=dennis.dalessandro@intel.com \
    --cc=dledford@redhat.com \
    --cc=julia@ni.com \
    --cc=kaike.wan@intel.com \
    --cc=leonro@mellanox.com \
    --cc=linux-kernel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).