On Fri 30-05-25 10:06:52, David Hildenbrand wrote:
> On 29.05.25 09:46, Michal Hocko wrote:
> > On Wed 28-05-25 23:01:04, David Hildenbrand wrote:
> > [...]
> > > I think we just have to be careful to document it properly -- especially
> > > the
> > > shortcomings and that this feature might becom
On 30.05.25 11:34, Jiri Bohac wrote:
On Fri, May 30, 2025 at 11:11:40AM +0200, David Hildenbrand wrote:
On 30.05.25 11:07, Michal Hocko wrote:
On Fri 30-05-25 10:39:39, David Hildenbrand wrote:
On 30.05.25 10:28, Michal Hocko wrote:
[...]
All that being said I would go with an additional par
On Fri, May 30, 2025 at 11:47:46AM +0200, David Hildenbrand wrote:
> > > > crashkernel=1G,cma,cma_sane_dma # no wait on transition
> > >
> > > But is no wait ok? I mean, any O_DIRECT with any device would at least
> > > take
> > > a bit, no?
> > >
> > > Of course, there is a short time between t
On Fri 30-05-25 11:47:46, David Hildenbrand wrote:
> On 30.05.25 11:34, Jiri Bohac wrote:
[...]
> > I am inclined to just setting the fixed delay to 10s for now and
> > adding a sysfs knob later if someone asks for it.
> >
> > Would that work for you?
>
> Sure. We could always add such a flag lat
On Fri, May 30, 2025 at 11:11:40AM +0200, David Hildenbrand wrote:
> On 30.05.25 11:07, Michal Hocko wrote:
> > On Fri 30-05-25 10:39:39, David Hildenbrand wrote:
> > > On 30.05.25 10:28, Michal Hocko wrote:
> > [...]
> > > > All that being said I would go with an additional parameter to the
> > >
On 30.05.25 11:26, Michal Hocko wrote:
On Fri 30-05-25 11:11:40, David Hildenbrand wrote:
On 30.05.25 11:07, Michal Hocko wrote:
On Fri 30-05-25 10:39:39, David Hildenbrand wrote:
On 30.05.25 10:28, Michal Hocko wrote:
[...]
All that being said I would go with an additional parameter to the
On Fri 30-05-25 11:11:40, David Hildenbrand wrote:
> On 30.05.25 11:07, Michal Hocko wrote:
> > On Fri 30-05-25 10:39:39, David Hildenbrand wrote:
> > > On 30.05.25 10:28, Michal Hocko wrote:
> > [...]
> > > > All that being said I would go with an additional parameter to the
> > > > kdump cma setu
On 30.05.25 11:07, Michal Hocko wrote:
On Fri 30-05-25 10:39:39, David Hildenbrand wrote:
On 30.05.25 10:28, Michal Hocko wrote:
[...]
All that being said I would go with an additional parameter to the
kdump cma setup - e.g. cma_sane_dma that would skip waiting and use 10s
otherwise. That woul
On Fri 30-05-25 10:39:39, David Hildenbrand wrote:
> On 30.05.25 10:28, Michal Hocko wrote:
[...]
> > All that being said I would go with an additional parameter to the
> > kdump cma setup - e.g. cma_sane_dma that would skip waiting and use 10s
> > otherwise. That would make the optimized behavior
On 30.05.25 10:28, Michal Hocko wrote:
On Fri 30-05-25 10:06:52, David Hildenbrand wrote:
On 29.05.25 09:46, Michal Hocko wrote:
On Wed 28-05-25 23:01:04, David Hildenbrand wrote:
[...]
I think we just have to be careful to document it properly -- especially the
shortcomings and that this feat
On 29.05.25 09:46, Michal Hocko wrote:
On Wed 28-05-25 23:01:04, David Hildenbrand wrote:
[...]
I think we just have to be careful to document it properly -- especially the
shortcomings and that this feature might become a problem in the future.
Movable user-space page tables getting placed on C
On Wed, May 28, 2025 at 11:01:04PM +0200, David Hildenbrand wrote:
> I think we just have to be careful to document it properly -- especially the
> shortcomings and that this feature might become a problem in the future.
> Movable user-space page tables getting placed on CMA memory would probably
>
On Thu 29-05-25 09:46:28, Michal Hocko wrote:
> On Wed 28-05-25 23:01:04, David Hildenbrand wrote:
> [...]
> > I think we just have to be careful to document it properly -- especially the
> > shortcomings and that this feature might become a problem in the future.
> > Movable user-space page tables
On Wed 28-05-25 23:01:04, David Hildenbrand wrote:
[...]
> I think we just have to be careful to document it properly -- especially the
> shortcomings and that this feature might become a problem in the future.
> Movable user-space page tables getting placed on CMA memory would probably
> not be a
On 04.03.25 05:20, Baoquan He wrote:
On 03/03/25 at 09:17am, Donald Dutile wrote:
On 3/3/25 3:25 AM, David Hildenbrand wrote:
On 20.02.25 17:48, Jiri Bohac wrote:
Hi,
this series implements a way to reserve additional crash kernel
memory using CMA.
Link to the v1 discussion:
https://lore.k
On Mon, Mar 03, 2025 at 09:25:30AM +0100, David Hildenbrand wrote:
> On 20.02.25 17:48, Jiri Bohac wrote:
> >
> > By reserving additional crashkernel memory from CMA, the main
> > crashkernel reservation can be just large enough to fit the
> > kernel and initrd image, minimizing the memory taken a
On 03/03/25 at 09:17am, Donald Dutile wrote:
>
>
> On 3/3/25 3:25 AM, David Hildenbrand wrote:
> > On 20.02.25 17:48, Jiri Bohac wrote:
> > > Hi,
> > >
> > > this series implements a way to reserve additional crash kernel
> > > memory using CMA.
> > >
> > > Link to the v1 discussion:
> > > http
On 3/3/25 3:25 AM, David Hildenbrand wrote:
On 20.02.25 17:48, Jiri Bohac wrote:
Hi,
this series implements a way to reserve additional crash kernel
memory using CMA.
Link to the v1 discussion:
https://lore.kernel.org/lkml/zwd_fapqewkfl...@dwarf.suse.cz/
See below for the changes since v1 a
On 20.02.25 17:48, Jiri Bohac wrote:
Hi,
this series implements a way to reserve additional crash kernel
memory using CMA.
Link to the v1 discussion:
https://lore.kernel.org/lkml/zwd_fapqewkfl...@dwarf.suse.cz/
See below for the changes since v1 and how concerns from the
discussion have been ad
On 02/20/25 at 05:48pm, Jiri Bohac wrote:
..snip...
> ---
> Changes since v1:
>
> The key concern raised in the v1 discussion was that pages in the
> CMA region may be pinned and used for a DMA transfer, potentially
> corrupting the new kernel's memory. When the cma suffix is used, kdump
> ma
Hi,
this series implements a way to reserve additional crash kernel
memory using CMA.
Link to the v1 discussion:
https://lore.kernel.org/lkml/zwd_fapqewkfl...@dwarf.suse.cz/
See below for the changes since v1 and how concerns from the
discussion have been addressed.
Currently, all the memory fo
21 matches
Mail list logo
