On Fri, Dec 12, 2014 at 03:07:23PM -0800, Vinson Lee wrote: > On Fri, Dec 12, 2014 at 2:45 PM, Luis R. Rodriguez <mcg...@suse.com> wrote: > > On Fri, Dec 12, 2014 at 02:38:26PM -0800, Vinson Lee wrote: > >> From: Nate Stahl <st...@twitter.com> > >> > >> A full task stack dump of all tasks on a machine can generate more than > >> 4MB of output to dmesg. Dumping this data to the serial console causes > >> the machine to hang for a number of minutes (an unacceptable impact), > >> but dumping the same data to memory is feasible if the dmesg buffer is > >> sized large enough to hold the output. Set to 16MB which will hopefully > >> be large enough to handle a dump from any of our servers at this time. > >> > >> Signed-off-by: Nate Stahl <st...@twitter.com> > >> Signed-off-by: Vinson Lee <v...@twitter.com> > > > > Isn't this the perpetual issue of having large number of CPUs? If so > > consider use of LOG_CPU_MAX_BUF_SHIFT instead, otherwise clarifying how > > this would be a different issue would be good. LOG_CPU_MAX_BUF_SHIFT > > should scale nicely but you can increase it as well, is it being used? > > > > Luis > > > No, it is not being used. > > LOG_CPU_MAX_BUF_SHIFT is a 3.17+ config and we do not have any of the > above mentioned production machines running 3.17 or later.
Then consider backporting it. > This patch did help us with debugging when running on older stable kernels > though. Understood, give the other stuff a spin. Luis -- 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/
