[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87cyjq7rjo.fsf@email.froward.int.ebiederm.org>
Date: Wed, 23 Oct 2024 10:44:11 -0500
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: Yan Zhao <yan.y.zhao@...el.com>, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-coco@...ts.linux.dev,
x86@...nel.org, rick.p.edgecombe@...el.com,
kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH] kexec_core: Accept unaccepted kexec destination addresses
"Kirill A. Shutemov" <kirill@...temov.name> writes:
> Waiting minutes to get VM booted to shell is not feasible for most
> deployments. Lazy is sane default to me.
Huh?
Unless my guesses about what is happening are wrong lazy is hiding
a serious implementation deficiency. From all hardware I have seen
taking minutes is absolutely ridiculous.
Does writing to all of memory at full speed take minutes? How can such
a system be functional?
If you don't actually have to write to the pages and it is just some
accounting function it is even more ridiculous.
I had previously thought that accept_memory was the firmware call.
Now that I see that it is just a wrapper for some hardware specific
calls I am even more perplexed.
Quite honestly what this looks like to me is that someone failed to
enable write-combining or write-back caching when writing to memory
when initializing the protected memory. With the result that everything
is moving dog slow, and people are introducing complexity left and write
to avoid that bad implementation.
Can someone please explain to me why this accept_memory stuff has to be
slow, why it has to take minutes to do it's job.
I would much rather spend my time figuring out how to make accept_memory
run at a reasonable speed than to litter the kernel with more of this
nonsense.
Eric
Powered by blists - more mailing lists