lkml.org 
[lkml]   [2012]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] mm: memmap_init_zone() performance improvement
    From
    Date
    On Mon, 2012-10-08 at 16:16 +0100, Mel Gorman wrote:
    > On Wed, Oct 03, 2012 at 08:56:14AM -0600, Mike Yoknis wrote:
    > > memmap_init_zone() loops through every Page Frame Number (pfn),
    > > including pfn values that are within the gaps between existing
    > > memory sections. The unneeded looping will become a boot
    > > performance issue when machines configure larger memory ranges
    > > that will contain larger and more numerous gaps.
    > >
    > > The code will skip across invalid sections to reduce the
    > > number of loops executed.
    > >
    > > Signed-off-by: Mike Yoknis <mike.yoknis@hp.com>
    >
    > This only helps SPARSEMEM and changes more headers than should be
    > necessary. It would have been easier to do something simple like
    >
    > if (!early_pfn_valid(pfn)) {
    > pfn = ALIGN(pfn + MAX_ORDER_NR_PAGES, MAX_ORDER_NR_PAGES) - 1;
    > continue;
    > }
    >
    > because that would obey the expectation that pages within a
    > MAX_ORDER_NR_PAGES-aligned range are all valid or all invalid (ARM is the
    > exception that breaks this rule). It would be less efficient on
    > SPARSEMEM than what you're trying to merge but I do not see the need for
    > the additional complexity unless you can show it makes a big difference
    > to boot times.
    >

    Mel,
    I, too, was concerned that pfn_valid() was defined in so many header
    files. But, I did not feel that it was appropriate for me to try to
    restructure things to consolidate those definitions just to add this one
    new function. Being a kernel newbie I did not believe that I had a good
    enough understanding of what combinations and permutations of CONFIG and
    architecture may have made all of those different definitions necessary,
    so I left them in.

    Yes, indeed, this fix is targeted for systems that have holes in memory.
    That is where we see the problem. We are creating large computer
    systems and we would like for those machines to perform well, including
    boot times.

    Let me pass along the numbers I have. We have what we call an
    "architectural simulator". It is a computer program that pretends that
    it is a computer system. We use it to test the firmware before real
    hardware is available. We have booted Linux on our simulator. As you
    would expect it takes longer to boot on the simulator than it does on
    real hardware.

    With my patch - boot time 41 minutes
    Without patch - boot time 94 minutes

    These numbers do not scale linearly to real hardware. But indicate to
    me a place where Linux can be improved.

    Mike Yoknis




    \
     
     \ /
      Last update: 2012-10-09 17:41    [W:5.245 / U:0.260 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site