On Tue, 16 Sep 2014 23:22:50 +0200 Jan Kara <j...@suse.cz> wrote: > > For the most part it's a blocking write. Yeah, if another CPU is > > writing, it wont be a blocking write, but it usually is, I know I > > depend on it (when I'm debugging, I usually don't have contention > > between CPUs). The important part is that they are done in order. A > > delayed print, wont be in order with other printks. That is still a > > crucial difference. > printk_deffered() will be in order with other printks after your commit > 458df9fd4815b47809875d57f42e16401674b621. Just printing to console itself > will be delayed to the next timer interrupt. Or am I missing something?
Hehe, you're right. I blame the meds for forgetting this. Yeah, my update will put the data in order. Thus I guess I agree with your assessment. We probably don't need the "sched_delayed" anymore. OK, you convinced me, but I still like to hear Peter's view on this before we commit it. For Markus's patch: Acked-by: Steven Rostedt <rost...@goodmis.org> -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
