>>> Phrasing it that way is non-sense. What is important is memory
>>> available in the system. A memory map is just a reflection upon that,
>>> a memory map is not the definition of truth.
>>>
>>> So if this notifier reflects when memory is coming and going on the
>>> system this is a reasonable
On 05/11/20 at 01:55pm, David Hildenbrand wrote:
> On 11.05.20 13:27, Baoquan He wrote:
> > On 05/11/20 at 10:19am, David Hildenbrand wrote:
> >> On 09.05.20 17:14, Eric W. Biederman wrote:
> > + * If the memory layout changes, any loaded kexec image should be
> > evicted
> > + * as it
>> kexec_load():
>>
>> 1. kexec-tools could have placed kexec images on memory that will be
>> removed.
>>
>> 2. the memory map of the guest is stale (esp., might still contain
>> hotunplugged memory). /sys/firmware/memmap and /proc/iomem will be
>> updated, so kexec-tools can fix this up.
>
> Wit
David Hildenbrand writes:
>>
>> Maybe we have enough information to fixup the loaded kexec image
>> in the kexec_file_load case, we certainly don't in the ordinary
>> kexec_load case.
>
> Yes, that's also what I mentioned in my reply to Baoquan.
>
>>
>> For now I want to stick to the simplest th
On 05/12/20 at 12:54pm, David Hildenbrand wrote:
> >> kexec_load():
> >>
> >> 1. kexec-tools could have placed kexec images on memory that will be
> >> removed.
> >>
> >> 2. the memory map of the guest is stale (esp., might still contain
> >> hotunplugged memory). /sys/firmware/memmap and /proc/iom
Hi,
I created an enhancement request for makedumpfile here,
https://github.com/makedumpfile/makedumpfile/issues/1
I found that compressing a flat core with gzip significantly reduces the size of
the core. Here were my findings,
32G flat elf core -E -F -d 0
33G kdump core -d 0
16G kdump compre
> On May 12, 2020, at 12:25 PM, Daniel Walker (danielwa)
> wrote:
>
>
> Hi,
>
> I created an enhancement request for makedumpfile here,
>
> https://urldefense.com/v3/__https://github.com/makedumpfile/makedumpfile/issues/1__;!!GqivPVa7Brio!LJIWfQ8ged-9RjjV00zqmBGbL2-UU0baDJmxqVXo5AxYcofHzP8
On Tue, May 12, 2020 at 12:38:42PM -0500, John Donnelly wrote:
>
> Hi Daniel.
>
>-z happens to be used by tar and rsync to indicate compression ;-) .
>
>
This would be fine with me,
makedumpfile -z -F -E -d 31 /proc/vmcore core.gz
Daniel
___
It's a quite interesting feature Daniel, thanks for the effort!
I'm curious about memory usage - did you somehow measure the
consumption with your patches vs. the regular kdump compression?
Thanks,
Guilherme
___
kexec mailing list
kexec@lists.infradea
On Tue, May 12, 2020 at 03:14:49PM -0300, Guilherme Piccoli wrote:
> It's a quite interesting feature Daniel, thanks for the effort!
> I'm curious about memory usage - did you somehow measure the
> consumption with your patches vs. the regular kdump compression?
It's not really a memory consumptio
Sure, I understood that. I'm curious though about the memory
consumption of the compression operation, or put in other words: do we
need to increase crashkernel reserved memory if we plan to use your
gzip approach?
It's good to be sure about this, to evaluate the trade-off of core
file size vs. nec
On Tue, May 12, 2020 at 03:32:25PM -0300, Guilherme Piccoli wrote:
> Sure, I understood that. I'm curious though about the memory
> consumption of the compression operation, or put in other words: do we
> need to increase crashkernel reserved memory if we plan to use your
> gzip approach?
> It's go
> -Original Message-
>
> Hi,
>
> I created an enhancement request for makedumpfile here,
>
> https://github.com/makedumpfile/makedumpfile/issues/1
>
> I found that compressing a flat core with gzip significantly reduces the size
> of
> the core. Here were my findings,
>
> 32G flat elf core
[+cc linux-pci]
On Mon, May 11, 2020 at 07:46:06PM -0700, Prabhakar Kushwaha wrote:
> An SMMU Stream table is created by the primary kernel. This table is
> used by the SMMU to perform address translations for device-originated
> transactions. Any crash (if happened) launches the kdump kernel whic
14 matches
Mail list logo
