On Sun, 18 Aug 2013 19:59:53 -0700 "Eric W. Biederman" <ebied...@xmission.com> wrote:
> > > > > > >Sorry Eric, I'm not clear to what you mean by ``short one core''... > >Which are you suggesting? Disabling BSP if crash happens on AP is > >reasonable? > >Or restricting cpus to a single one only just as the current kdump > >configuration is reasonable? > > I am suggesting we start every cpu except the BSP from the AP we started on. > > N-1 cpus seems like a good tradeoff between performance and reliability for > those who need it. FWIW a large customers of ours is fine with such a limitation. And I have already tested this approach manually (starting the kdump kernel with maxcpus=1 and hot-plugging the remaining APs from user-space). Now that this approach is in line with upstream efforts, I'm going to test it on some more machines and see if there are any troubles. @Hatayama-san: > BTW, I have question that does normal kdump work well if crash happens > on some AP? I wonder the same issue could happen on the 2nd kernel. I'm not sure what you mean. Normal kdump starts with "maxcpus=1", and yes, that works even if the secondary kernel is booted from an AP. OTOH I suspect that not having any BSP in the system may be the cause of some mysterious random reboots and/or hangs experienced by some customers. I'll try setting the BSP flag on the boot CPU unconditionally and see if it makes any difference. Petr Tesarik -- 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/
