On 10/15/19 7:09 AM, Guilherme G. Piccoli wrote:
>
>
> On 10/15/19 11:05 AM, Michal Hocko wrote:
>> On Tue 15-10-19 10:58:36, Guilherme G. Piccoli wrote:
>>> On 10/15/19 9:18 AM, Michal Hocko wrote:
I do agree with Qian Cai here. Kdump kernel requires a very tailored
environment conside
On 10/15/19 11:05 AM, Michal Hocko wrote:
On Tue 15-10-19 10:58:36, Guilherme G. Piccoli wrote:
On 10/15/19 9:18 AM, Michal Hocko wrote:
I do agree with Qian Cai here. Kdump kernel requires a very tailored
environment considering it is running in a very restricted
configuration. The hugetlb
On Tue 15-10-19 10:58:36, Guilherme G. Piccoli wrote:
> On 10/15/19 9:18 AM, Michal Hocko wrote:
> > I do agree with Qian Cai here. Kdump kernel requires a very tailored
> > environment considering it is running in a very restricted
> > configuration. The hugetlb pre-allocation sounds like a toolin
On 10/15/19 9:18 AM, Michal Hocko wrote:
I do agree with Qian Cai here. Kdump kernel requires a very tailored
environment considering it is running in a very restricted
configuration. The hugetlb pre-allocation sounds like a tooling problem
and should be fixed at that layer.
Hi Michal, thanks
On Fri 11-10-19 21:41:01, Guilherme Piccoli wrote:
> On Fri, Oct 11, 2019 at 8:52 PM Qian Cai wrote:
> >
> >
> > It simply error-prone to reuse the sysctl.conf from the first kernel, as it
> > could contains lots of things that will kill kdump kernel.
>
> Makes sense, I agree with you. But still
On 14/10/2019 15:25, Mike Kravetz wrote:
> [...]
> I don't know much about early_param(), so I will assume this works as you
> describe. However, a quick grep shows hugepage options for ia64 also with
> early_param.
>
Thanks a lot for the prompt and quite informative reply Mike.
I've checked th
On 10/11/19 3:39 PM, Guilherme G. Piccoli wrote:
> Currently there are 2 ways for setting HugeTLB hugepages in kernel; either
> users pass parameters on kernel command-line or they can write to sysfs
> files (which is effectively the sysctl way).
>
> Kdump kernels won't benefit from hugepages - in
On Fri, Oct 11, 2019 at 8:52 PM Qian Cai wrote:
>
>
> It simply error-prone to reuse the sysctl.conf from the first kernel, as it
> could contains lots of things that will kill kdump kernel.
Makes sense, I agree with you. But still, there's no
formal/right/single way to do kdump, so I don't thin
> On Oct 11, 2019, at 7:42 PM, Guilherme Piccoli wrote:
>
> Thanks for the quick response. Kdump in Ubuntu, for example, rely in
> mounting the root filesystem.
> Even in initrd-only approaches, we could have sysctl.conf being copied
> to initramfs, and hugepages end-up getting set.
It simply
On Fri, Oct 11, 2019 at 8:36 PM Qian Cai wrote:
>
> Typically, kdump kernel has its own initramfs, and don’t even need to mount a
> rootfs, so I can’t see how sysfs/sysctl is relevant here.
Thanks for the quick response. Kdump in Ubuntu, for example, rely in
mounting the root filesystem.
Even in
> On Oct 11, 2019, at 6:40 PM, Guilherme G. Piccoli
> wrote:
>
> Kdump kernels won't benefit from hugepages - in fact it's quite opposite,
> it may be the case hugepages on kdump kernel can lead to OOM if kernel
> gets unable to allocate demanded pages due to the fact the preallocated
> hugep
Currently there are 2 ways for setting HugeTLB hugepages in kernel; either
users pass parameters on kernel command-line or they can write to sysfs
files (which is effectively the sysctl way).
Kdump kernels won't benefit from hugepages - in fact it's quite opposite,
it may be the case hugepages on
12 matches
Mail list logo
