Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1457643
| From | Hari Bathini <hbathini@linux.vnet.ibm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range |
| Date | 2016-08-08 11:30 +0200 |
| Message-ID | <s3P2F-7YV-15@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <s2abg-6TC-7@gated-at.bofh.it> <s2nrQ-76H-17@gated-at.bofh.it> <s2w25-4Tj-11@gated-at.bofh.it> <s3NWW-7is-11@gated-at.bofh.it> <s3OzE-7xb-23@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Monday 08 August 2016 02:26 PM, Michael Ellerman wrote: > Hari Bathini <hbathini@linux.vnet.ibm.com> writes: >> On Friday 05 August 2016 12:23 AM, Hari Bathini wrote: >>> On Thursday 04 August 2016 03:15 PM, Michael Ellerman wrote: >>>> The code already knows how to reserve 5% based on the size of the >>>> machine's >>>> memory, as long as no commandline parameter is passed. So why can't we >>>> just use that logic? >>> That is the default value reserved but not a good enough value for >>> every case. It is a bit difficult to come up with a robust formula >>> that works for every case as new kernel changes could make the >>> values obsolete. But it won't be all that difficult to find values that >>> work for different memory ranges for a given kernel version. >>> Passing that as range based input with "fadump_reserve_mem" >>> parameter would work for every memory configuration on a >>> given system, which is what this patch is trying to provide.. >> You want me to add this to the changelog on respin? Hi Michael, > I'm not really convinced. > > Distros are going to want to specify a fixed set of values for different > memory sizes, at least that's what I've seen in the past with kdump. So > I don't see why we can't just do that in the kernel with a formula based > on memory size, and maybe some other information. Agreed. Such support would be great but this patch is adding support for a new syntax for an existing parameter which should still be good to have? > Maybe the formula is more complicated than 5% of RAM, but it shouldn't > be *that* much more complicated. Depending on what all kernel versions that need support, this can get ugly? I could be completely wrong though.. Thanks Hari > cheers > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec >
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range Hari Bathini <hbathini@linux.vnet.ibm.com> - 2016-08-03 21:40 +0200
Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range Michael Ellerman <mpe@ellerman.id.au> - 2016-08-04 11:50 +0200
Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range Hari Bathini <hbathini@linux.vnet.ibm.com> - 2016-08-04 21:00 +0200
Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range Hari Bathini <hbathini@linux.vnet.ibm.com> - 2016-08-08 10:20 +0200
Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range Michael Ellerman <mpe@ellerman.id.au> - 2016-08-08 11:00 +0200
Re: [RESEND][PATCH v2 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range Hari Bathini <hbathini@linux.vnet.ibm.com> - 2016-08-08 11:30 +0200
csiph-web