On Thu, 5 Oct 2017, Julia Cartwright wrote: > On Thu, Oct 05, 2017 at 11:55:39AM -0400, Steven Rostedt wrote: > > On Thu, 5 Oct 2017 10:37:59 -0500 > > Julia Cartwright <julia@xxxxxx> wrote: > > > > > On Thu, Oct 05, 2017 at 05:27:30PM +0200, Thomas Gleixner wrote: > > > > On Thu, 5 Oct 2017, Julia Cartwright wrote: > > > > > On Tue, Oct 03, 2017 at 12:49:19PM -0300, Arnaldo Carvalho de Melo wrote: > > > > > > - preempt_disable(); > > > > > > + preempt_disable_nort(); > > > > > > this_cpu_inc(*sc->buffers_allocated); > > > > > > > > > > Have you tried this on RT w/ CONFIG_DEBUG_PREEMPT? I believe that the > > > > > this_cpu_* operations perform a preemption check, which we'd trip. > > > > > > > > Good point. Changing this to migrate_disable() would do the trick. > > > > > > Wouldn't we still trip the preempt check even with migration disabled? > > > In another thread I asked the same question: should the preemption > > > checks here be converted to migration-checks in RT? > > > > Is it a "preemption check"? > > Sorry if I was unclear, more precisely: the this_cpu_* family of > accessors, w/ CONFIG_DEBUG_PREEMPT currently spits out a warning when > the caller is invoked in a context where preemption is enabled. > > The check is shared w/ the smp_processor_id() check, as implemented in > lib/smp_processor_id.c. It effectively boils down to a check of > preempt_count() and irqs_disabled(). Except that on RT that check cares about the migrate disable state. You can invoke this_cpu_* and smp_processor_id() in preemptible/interruptible context because of: if (cpumask_equal(current->cpus_ptr, cpumask_of(this_cpu))) goto out; That's true even on mainline. But you are right that this check needs some update because migrate_disable() does not immediately update the allowed cpumask IIRC. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
