On Mon, Apr 07, 2025 at 11:16:26AM -0300, Jason Gunthorpe wrote:
> On Sun, Apr 06, 2025 at 07:11:14PM +0300, Mike Rapoport wrote:
>
> KHO needs to provide a way to give back an allocated struct page/folio
> that can be freed back to the buddy alloactor, of the proper
> order. Whatever you call tha
On Fri, Apr 04, 2025 at 04:24:54PM +, Pratyush Yadav wrote:
> On Fri, Apr 04 2025, Jason Gunthorpe wrote:
> >
> > I'm pretty sure this is going to be the best performance path, but I
> > have no idea how invasive it would be to the buddy alloactor to make
> > it work.
>
> I don't imagine it wo
On Fri, Apr 04, 2025 at 09:47:29AM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 04, 2025 at 12:54:25PM +0300, Mike Rapoport wrote:
> > > IMHO it should not call kho_preserve_phys() at all.
> >
> > Do you mean that for preserving large physical ranges we need something
> > entirely different?
>
> I
Hi Pratyush,
Thanks for reviewing!
On Wed, Apr 02, 2025 at 19:16:27 +, Pratyush Yadav
wrote:
> Hi Changyuan,
>
> On Wed, Mar 19 2025, Changyuan Lyu wrote:
> > [...]
> > +int kho_preserve_phys(phys_addr_t phys, size_t size)
> > +{
> > + unsigned long pfn = PHYS_PFN(phys), end_pfn = PHYS_PF
Hi all,
I am happy to announce the release of kexec-tools 2.0.31-rc1.
This is an incremental feature pre-release.
So long as no serious problems arise I intend to release kexec-tools 2.0.31
in a weeks time. Testing of 2.0.31-rc1 would be greatly appreciated.
I do not have any outstanding change
On Thu, Apr 03, 2025 at 01:10:01PM -0300, Jason Gunthorpe wrote:
> On Thu, Apr 03, 2025 at 03:50:04PM +, Pratyush Yadav wrote:
>
> > +struct kho_mem_track {
> > + /* Points to L4 KHOMEM descriptor, each order gets its own table. */
> > + struct xarray orders;
> > +};
>
> I think it would
Hi Mike,
On Fri, Apr 04 2025, Mike Rapoport wrote:
[...]
> As for the optimizations of memblock reserve path, currently it what hurts
> the most in my and Pratyush experiments. They are not very representative,
> but still, preserving lots of pages/folios spread all over would have it's
> toll on
On Fri, Apr 04 2025, Jason Gunthorpe wrote:
> On Thu, Apr 03, 2025 at 05:37:06PM +, Pratyush Yadav wrote:
>
[...]
>> > This should be more like:
>> >
>> > union {
>> > void *table;
>> > phys_addr_t table_phys;
>> > };
>> >
>> > Since we are not using the low bits right now and it i
On Mon, Apr 07, 2025 at 07:31:21PM +0300, Mike Rapoport wrote:
> > alloc_pages is a 0 order "folio". vmalloc is an array of 0 order
> > folios (?)
>
> According to current Matthew's plan [1] vmalloc is misc memory :)
Someday! :)
> Ok, let's stick with memdesc then. Put aside the name it looks li
On Thu, Apr 10, 2025 at 05:51:51PM +0100, Matthew Wilcox wrote:
> On Wed, Apr 09, 2025 at 01:28:37PM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 09, 2025 at 07:19:30PM +0300, Mike Rapoport wrote:
> > > But we have memdesc today, it's struct page.
> >
> > No, I don't think it is. struct page seem
From: Nick Kossifidis
This patch adds support for loading the ELF kernel image. It parses
the current/provided device tree to determine the system's memory
layout, and /proc/iomem for the various kernel segments.
Tested on Qemu's rv64 virt machine and SoC of T-Head RISC-V Xuantie
910 CPU.
Now,
On Wed, Apr 09, 2025 at 01:28:37PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 09, 2025 at 07:19:30PM +0300, Mike Rapoport wrote:
> > But we have memdesc today, it's struct page.
>
> No, I don't think it is. struct page seems to be turning into
> something legacy that indicates the code has not be
On Wed, Apr 09, 2025 at 12:37:14PM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 09, 2025 at 04:58:16PM +0300, Mike Rapoport wrote:
> > >
> > > I think we still don't really know what will be needed, so I'd stick
> > > with folio only as that allows building the memfd and a potential slab
> > > prese
On Fri, Apr 04, 2025 at 11:30:31AM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 04, 2025 at 04:53:13PM +0300, Mike Rapoport wrote:
> > > Maybe change the reserved regions code to put the region list in a
> > > folio and preserve the folio instead of using FDT as a "demo" for the
> > > functionality.
On Wed, Apr 09, 2025 at 07:19:30PM +0300, Mike Rapoport wrote:
> On Wed, Apr 09, 2025 at 12:37:14PM -0300, Jason Gunthorpe wrote:
> > On Wed, Apr 09, 2025 at 04:58:16PM +0300, Mike Rapoport wrote:
> > > >
> > > > I think we still don't really know what will be needed, so I'd stick
> > > > with foli
On Wed, Apr 09, 2025 at 04:58:16PM +0300, Mike Rapoport wrote:
> > I'm not sure that is consistent with what Matthew is trying to build,
> > I think we are trying to remove 'struct page' usage, especially for
> > compound pages. Right now, though it is confusing, folio is the right
> > word to enco
On Mon, Apr 07, 2025 at 02:03:05PM -0300, Jason Gunthorpe wrote:
> On Mon, Apr 07, 2025 at 07:31:21PM +0300, Mike Rapoport wrote:
> >
> > Ok, let's stick with memdesc then. Put aside the name it looks like we do
> > agree that KHO needs to provide a way to preserve memory allocated from
> > buddy a
On Wed, Apr 09, 2025 at 07:28:47PM +0300, Mike Rapoport wrote:
> On Mon, Apr 07, 2025 at 11:16:26AM -0300, Jason Gunthorpe wrote:
> > On Sun, Apr 06, 2025 at 07:11:14PM +0300, Mike Rapoport wrote:
> >
> > KHO needs to provide a way to give back an allocated struct page/folio
> > that can be freed
On Mon, Apr 07, 2025 at 11:16:26AM -0300, Jason Gunthorpe wrote:
> On Sun, Apr 06, 2025 at 07:11:14PM +0300, Mike Rapoport wrote:
> > > > > We know what the future use case is for the folio preservation, all
> > > > > the drivers and the iommu are going to rely on this.
> > > >
> > > > We don't kn
On Wed, Apr 09, 2025 at 12:06:27PM +0300, Mike Rapoport wrote:
> Now we've settled with terminology, and given that currently memdesc ==
> struct page, I think we need kho_preserve_folio(struct *folio) for actual
> struct folios and, apparently other high order allocations, and
> kho_preserve_page
On Sun, Apr 06, 2025 at 07:34:30PM +0300, Mike Rapoport wrote:
> It's more than 200 line longer than maple tree if we count the lines.
> My point is both table and xarrays are trying to optimize for an unknown
> goal.
Not unknown, the point of the bitmap scheme is to be memory
deterministic.
You
On Fri, Apr 04, 2025 at 04:53:13PM +0300, Mike Rapoport wrote:
> > Maybe change the reserved regions code to put the region list in a
> > folio and preserve the folio instead of using FDT as a "demo" for the
> > functionality.
>
> Folios are not available when we restore reserved regions, this jus
On Fri, Apr 04, 2025 at 04:15:28PM +, Pratyush Yadav wrote:
> Hi Mike,
>
> On Fri, Apr 04 2025, Mike Rapoport wrote:
>
> [...]
> > As for the optimizations of memblock reserve path, currently it what hurts
> > the most in my and Pratyush experiments. They are not very representative,
> > but
On Fri, Apr 04 2025, Jason Gunthorpe wrote:
> On Fri, Apr 04, 2025 at 04:53:13PM +0300, Mike Rapoport wrote:
[...]
>> Most drivers do not use folios
>
> Yes they do, either through kmalloc or through alloc_page/etc. "folio"
> here is just some generic word meaning memory from the buddy allocator.
24 matches
Mail list logo
