lkml.org 
[lkml]   [2017]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE
    On 03/03/17 at 01:16pm, Borislav Petkov wrote:
    > On Fri, Mar 03, 2017 at 08:06:16PM +0800, Baoquan He wrote:
    > > OK, I am trying to make things clearer, seems I failed. I thought kernel
    > > iamge size is only allowed to be 512M at most, but can be mapped into 1G
    > > region.
    >
    > It doesn't look like it. But we could be missing something. You could
    > try some git archeology to find out why the 512M limit. It could be "no
    > reason", it could be remnant from 32-bit, it could be anything...
    >
    > There's the full git history here too:
    >
    > https://git.kernel.org/cgit/linux/kernel/git/history/history.git
    >
    > in case it helps.

    Thanks, have got all related change history below. In the last commit log
    Ingo wrote he was just trying to give more space to kernel and push
    modules up a bit, and it should be enough for a few years. My thought of
    introducing KERNEL_MAPPING_SIZE is mainly because in commit 85eb69a1
    ("x86: increase the kernel text limit to 512 MB") Ingo is trying to
    increase kernel image size, since the really large static arrays and
    building allyesconfig kernel are all bloating kernel image. I feel Ingo
    is very careful to keep the pace to increase it, guess people don't want
    to see kernel image can be made by default as 1G big at one time without
    obvious reason. AFAIK, peopel sometime have to tell how much space it
    will increae with their new feature or big change. This is a very good
    self alert with a limited but usually enough value, 512M, let people pay
    attention to the elegacy but not always many lines of code, think more
    and refector code. And linker script is the guard to check it.

    Not sure if I make myself clear. I hesitated to do that earlier, so
    finally introduce KERNEL_MAPPING_SIZE. Surely in the current case, as
    you said, 1G is hard-constrainted line, unless we decide to give a
    larger space for kernel mapping or put it other place since Intel people
    have been working on 5-level page mapping thing, we don't lack virtual
    space, but kernel mapping is too constrainted. Even though we have more
    than 1G kernel mapping space, image size still should be limited to a
    small value, like plus 128M or + 256M.

    ***
    commit 85eb69a16aab5a394ce043c2131319eae35e6493
    Author: Ingo Molnar <mingo@elte.hu>
    Date: Thu Feb 21 12:50:51 2008 +0100

    x86: increase the kernel text limit to 512 MB

    people sometimes do crazy stuff like building really large static
    arrays into their kernels or building allyesconfig kernels. Give
    more space to the kernel and push modules up a bit: kernel has
    512 MB and modules have 1.5 GB.

    Should be enough for a few years ;-)

    ***
    d4afe414 x86: rename KERNEL_TEXT_SIZE => KERNEL_IMAGE_SIZE
    Rename it to be KERNEL_IMAGE_SIZE

    ***
    88f3aec7 x86: fix spontaneous reboot with allyesconfig bzImage
    In this commit Ingo changed KERNEL_TEXT_SIZE from 40M to 128M.

    >
    > > It's fine to me, thing can be solved anyway. Will repost with
    > > KERNEL_IMAGE_SIZE by default 1G.
    >
    > I think you should slow down first and try to find out why the 512
    > default. Then we can talk about changes.
    >
    > --
    > Regards/Gruss,
    > Boris.
    >
    > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
    > --

    \
     
     \ /
      Last update: 2017-03-03 16:20    [W:4.190 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site