On 12/07/23 at 09:55am, Michal Hocko wrote: > On Thu 07-12-23 12:23:13, Baoquan He wrote: > [...] > > We can't guarantee how swift the DMA transfer could be in the cma, case, > > it will be a venture. > > We can't guarantee this of course but AFAIK the DMA shouldn't take > minutes, right? While not perfect, waiting for some time before jumping > into the crash kernel should be acceptable from user POV and it should > work around most of those potential lingering programmed DMA transfers. > > So I guess what we would like to hear from you as kdump maintainers is > this. Is it absolutely imperative that these issue must be proven > impossible or is a best effort approach something worth investing time > into? Because if the requirement is an absolute guarantee then I simply > do not see any feasible way to achieve the goal of reusable memory. Honestly, I think all the discussions and proof have told clearly it's not a good idea. This is not about who wants this, who doesn't. So far, this is an objective fact that taking ,cma area for crashkernel= is not a good idea, it's very risky. We don't deny this at the beginning. I tried to present all what I know, we have experienced, we have investigated, we have tried. I wanted to see if this time we can clarify some concerns may be mistaken. But it's not. The risk is obvious and very likely happen. > > Let me reiterate that the existing reservation mechanism is showing its > limits for production systems and I strongly believe this is something > that needs addressing because crash dumps are very often the only tool > to investigate complex issues. Yes, I admit that. But it haven't got to the point that it's too bad to bear so that we have to take the risk to take ,cma instead. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
