"Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx> writes: > On Fri, Feb 14, 2025 at 08:20:07AM -0800, Dave Hansen wrote: >> On 2/14/25 05:46, Kirill A. Shutemov wrote: >> >> It sounds like you're advocating for the "slow guest boot" option. >> >> Kirill, can you remind us how fast a guest boots to the shell for >> >> modestly-sized (say 256GB) memory with "accept_memory=eager" versus >> >> "accept_memory=lazy"? IIRC, it was a pretty remarkable difference. >> > I only have 128GB machine readily available and posted some number on >> > other thread[1]: >> > >> > On single vCPU it takes about a minute to accept 90GiB of memory. >> > >> > It improves a bit with number of vCPUs. It is 40 seconds with 4 vCPU, but >> > it doesn't scale past that in my setup. >> > >> > I've mentioned it before in other thread: >> > >> > [1] https://lore.kernel.org/all/ihzvi5pwn5hrn4ky2ehjqztjxoixaiaby4igmeihqfehy2vrii@tsg6j5qvmyrm >> >> Oh, wow, from that other thread, you've been trying to get this crash >> fix accepted since November? >> >> From the looks of it, Eric stopped responding to that thread. I _think_ >> you gave a reasonable explanation of why memory acceptance is slow. He >> then popped back up last month raising security concerns. But I don't >> see anyone that shares those concerns. >> >> The unaccepted memory stuff is also _already_ touching the page >> allocator. If it's a dumb idea, then we should be gleefully ripping it >> out of the page allocator, not rejecting a 2-line kexec patch. >> >> Baoquan has also said this looks good to him. >> >> I'm happy to give Eric another week to respond in case he's on vacation >> or something, but I'm honestly not seeing a good reason to hold this bug >> fix up. >> >> Andrew, is this the kind of thing you can stick into mm and hold on to >> for a bit while we give Eric time to respond? > > Andrew, Eric, can we get this patch in? How goes the work to fix this horrifically slow firmware interface? Eric
