On Fri, 30 May 2014, Jan Kara wrote: > > Documentation/kernel-parameters.txt | 19 +- > > kernel/printk/printk.c | 1218 > > +++++++++++++++++++++++++---------- > > 2 files changed, 878 insertions(+), 359 deletions(-) > > > > > > Your patches look clean and pretty nice actually. They must be seriously > > considered if we want to keep the current locked ring buffer design and > > extend it to multiple per context buffers. But I wonder if it's worth to > > continue that way with the printk ancient design. > > > > If it takes more than 1000 line changes (including 500 added) to make it > > finally work correctly with NMIs by working around its fundamental flaws, > > shouldn't we rather redesign it to use a lockless ring buffer like ftrace > > or perf ones? > I agree that lockless ringbuffer would be a more elegant solution but a > much more intrusive one and complex as well. Petr's patch set basically > leaves ordinary printk path intact to avoid concerns about regressions > there.
Fully agreed, vast majority of the changes done by the patchset are on the unlikely in-NMI path, leaving normal printk operation as-is. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
