linux-kernel - Re: [PATCH v5 09/16] kexec: enable KHO support for memory preservation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <mafs0tt7eqt6f.fsf@amazon.de>
Date: Thu, 27 Mar 2025 17:28:40 +0000
From: Pratyush Yadav <ptyadav@...zon.de>
To: Jason Gunthorpe <jgg@...dia.com>
CC: Changyuan Lyu <changyuanl@...gle.com>, <linux-kernel@...r.kernel.org>,
	<graf@...zon.com>, <akpm@...ux-foundation.org>, <luto@...nel.org>,
	<anthony.yznaga@...cle.com>, <arnd@...db.de>, <ashish.kalra@....com>,
	<benh@...nel.crashing.org>, <bp@...en8.de>, <catalin.marinas@....com>,
	<dave.hansen@...ux.intel.com>, <dwmw2@...radead.org>,
	<ebiederm@...ssion.com>, <mingo@...hat.com>, <jgowans@...zon.com>,
	<corbet@....net>, <krzk@...nel.org>, <rppt@...nel.org>,
	<mark.rutland@....com>, <pbonzini@...hat.com>, <pasha.tatashin@...een.com>,
	<hpa@...or.com>, <peterz@...radead.org>, <robh+dt@...nel.org>,
	<robh@...nel.org>, <saravanak@...gle.com>,
	<skinsburskii@...ux.microsoft.com>, <rostedt@...dmis.org>,
	<tglx@...utronix.de>, <thomas.lendacky@....com>, <usama.arif@...edance.com>,
	<will@...nel.org>, <devicetree@...r.kernel.org>, <kexec@...ts.infradead.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-doc@...r.kernel.org>,
	<linux-mm@...ck.org>, <x86@...nel.org>
Subject: Re: [PATCH v5 09/16] kexec: enable KHO support for memory preservation

On Thu, Mar 27 2025, Jason Gunthorpe wrote:

> On Thu, Mar 27, 2025 at 10:03:17AM +0000, Pratyush Yadav wrote:
>
>> Of course, with the current linked list structure, this cannot work. But
>> I don't see why we need to have it. I think having a page-table like
>> structure would be better -- only instead of having PTEs at the lowest
>> levels, you have the bitmap.
>
> Yes, but there is a trade off here of what I could write in 30 mins
> and what is maximally possible :) The xarray is providing a page table
> implementation in a library form.
>
> I think this whole thing can be optimized, especially the
> memblock_reserve side, but the idea here is to get started and once we
> have some data on what the actual preservation workload is then
> someone can optimize this.
>
> Otherwise we are going to be spending months just polishing this one
> patch without any actual data on where the performance issues and hot
> spots actually are.

The memblock_reserve side we can optimize later, I agree. But the memory
preservation format is ABI and I think that is worth spending a little
more time on. And I don't think it should be that much more complex than
the current format.

I want to hack around with it, so I'll give it a try over the next few
days and see what I can come up with.

-- 
Regards,
Pratyush Yadav