linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>, David Miller <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	benh@kernel.crashing.org, hpa@zytor.com,
	jbarnes@virtuousgeek.org, ebiederm@xmission.com,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.cy
Date: Mon, 22 Mar 2010 16:41:13 -0700	[thread overview]
Message-ID: <4BA80019.5000900@kernel.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1003222329050.3147@localhost.localdomain>

On 03/22/2010 03:53 PM, Thomas Gleixner wrote:
> On Mon, 22 Mar 2010, Yinghai Lu wrote:
>> On 03/22/2010 03:09 PM, Thomas Gleixner wrote:
>>> On Mon, 22 Mar 2010, Yinghai Lu wrote:
>>>> On 03/22/2010 12:37 PM, Ingo Molnar wrote:
>>
>>>> 1. need to keep e820
>>>
>>>   That's neither an argument for using lmb nor an argument not to use
>>>   lmb. e820 is x86 specific BIOS wreckage and it's whole purpose is
>>>   just to feed information into a (hopefully) generic early resource
>>>   management facility.
>>>
>>>   e820 _CANNOT_ be generalized. Period.
> 
>   I still want to know, what "need to keep e820" means for you.

keep the most arch/x86/kernel/e820.c, and later when finish_e820_parsing() is called,
fill lmb.memory according to e820 entries with E820_RAM type.



>  
>>>> 2. use e820 range with RAM to fill lmb.memory when finizing_e820
>>>
>>>   What's finizing_e820 ???
>>  finish_e820_parsing();
> 
>  Yinghai, come on. Are you really expecting that everyone involved in
>  this discussion goes to look up what the heck finish_e820_parsing()
>  is doing ?
> 
>  You want to explain why your solution is better or why lmb is not
>  sufficient, so you better go and explain what finish_e820_parsing()
>  is, why finish_e820_parsing() is important and why lmb cannot cope
>  with it.

current x86:
a. setup e820 array.
b. early_parm mem= and memmap= related code will adjust the e820.

we don't need to call lmb_enforce_memory_limit().

> 
>>>> 3. use lmb.reserved to replace early_res.
>>>
>>>   What's the implication of doing that ?
>>
>> early_res array is only corresponding to lmb.reserved, aka reserved
>> region from kernel.
>  
>  Is it only corresponding (somehow) or is it a full equivivalent ?

early_res is not sorted and merged.

> 
>>>> current lmb is merging the region, we can not use name tag any more.
>>>
>>>   What's wrong with merging of regions ? Are you arguing about a
>>>   specific region ("the region") ?
> 
>  Care to answer my question ?
if range get merged, you can not use name with them.
>  
>>>
>>>   Which name tag ? And why is that name tag important ?
>>
>> struct early_res {
>>         u64 start, end;
>>         char name[15];
>>         char overlap_ok;
>> };
> 
>  I'm starting to get annoyed, really. What is that name field for and
>  why is that "name" field important ?

at least later when some code free a wrong range, we can figure who cause the problem.

> 
>>>  
>>>> may need to dump early_memtest, and use early_res for bootmem at
>>>> first.
>>>
>>>   Why exactly might early_memtest not longer be possible ?
>>
>> early_memtest need to call find_e820_area_size
>> current lmb doesn't have that kind of find util.
>> the one memory subtract reserved memory by kernel.
> 
>  What subtracts what ? And why is it that hard to fix that ?

lmb.memory - lmb.reserved

or e820 E820_RAM entries - early_res

move some code from early_res to lmb.c? 

> 
>>>
>>>   What means "early_res for bootmem" ?
>>
>> use early_res to replace bootmem, the CONFIG_NO_BOOTMEM.
>> that need early_res can be double or increase the slots automatically.
> 
>  -ENOPARSE
> 
> Yinghai, I asked you to take your time and explain things in detail
> instead of shooting unparseable answers within a minute.
> 
> Everyone else in this discussion tries to be as explanatory as
> possible, just you expect that everyone else is going to dig out the
> crystal ball to understand the deeper meanings of your patches.
> 
> Again, please take your time to explain what needs to be done or what
> is impossible to solve in your opinion, so we can get that resolved in
> a way which is satisfactory and useful for all parties involved.

to make x86 to use lmb, we need to extend lmb to have find_early_area.

static int __init find_overlapped_early(u64 start, u64 end)
{
        int i;
        struct lmb_properties *r;

        for (i = 0; i < lmb.reserved_cnt && lmb.reserved.region[i].size; i++) {
                r = &lmb.reserved.region[i];
                if (end > r->base && start < (r->base + r->size))
                        break;
        }

        return i;
}


/* Check for already reserved areas */
static inline int __init bad_addr(u64 *addrp, u64 size, u64 align)
{
        int i;
        u64 addr = *addrp;
        int changed = 0;
        struct lmb_properties *r;
again:
        i = find_overlapped_early(addr, addr + size);
        r = &lmb.reserved.region[i];
        if (i < lmb.reserved.cnt && r->size) {
                *addrp = addr = round_up(r->base + r->size, align);
                changed = 1;
                goto again;
        }
        return changed;
}

u64 __init find_early_area(u64 ei_start, u64 ei_last, u64 start, u64 end,
                         u64 size, u64 align)
{
        u64 addr, last;

        addr = round_up(ei_start, align);
        if (addr < start)
                addr = round_up(start, align);
        if (addr >= ei_last)
                goto out;
        while (bad_addr(&addr, size, align) && addr+size <= ei_last)
                ;
        last = addr + size;
        if (last > ei_last)
                goto out;
        if (last > end)
                goto out;

        return addr;

out:
        return -1ULL;
}

find_early_area_size()...

and use them we can have find_lmb_free_area

/*
 * Find a free area with specified alignment in a specific range.
 */
u64 __init find_lmb_area(u64 start, u64 end, u64 size, u64 align)
{
        int i;

        for (i = 0; i < lmb.memory.cnt; i++) {
                u64 ei_start = lmb.memory.region[i].base;
                u64 ei_end = ei_start + lmb.memory.region[i].size;

                addr = find_early_area(ei_start, ei_last, start, end,
                                         size, align);

                if (addr != -1ULL)
                        return addr;
        }
        return -1ULL;
}


also later we can use with active_range for bootmem replacement.

u64 __init find_memory_core_early(int nid, u64 size, u64 align,
                                        u64 goal, u64 limit)
{
        int i;

        /* need to go over early_node_map to find out good range for node */
        for_each_active_range_index_in_nid(i, nid) {
                u64 addr;
                u64 ei_start, ei_last;

                ei_last = early_node_map[i].end_pfn;
                ei_last <<= PAGE_SHIFT;
                ei_start = early_node_map[i].start_pfn;
                ei_start <<= PAGE_SHIFT;
                addr = find_early_area(ei_start, ei_last,
                                         goal, limit, size, align);

                if (addr == -1ULL)
                        continue;

                return addr;
        }

        return -1ULL;
}


Yinghai

  reply	other threads:[~2010-03-22 23:42 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-21  7:13 [PATCH 00/20] x86: early_res and irq_desc Yinghai Lu
2010-03-21  7:13 ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 01/20] x86: add find_e820_area_node Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 02/20] x86: add get_centaur_ram_top Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 03/20] x86: make e820 to be static Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 04/20] x86: use wake_system_ram_range instead of e820_any_mapped in agp path Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 05/20] x86: make e820 to be initdata Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.c Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-22  2:37   ` Benjamin Herrenschmidt
2010-03-22  2:46     ` Questions about SMP bootup control Zhu, Yijun (NSN - CN/Beijing)
2010-03-22  2:46       ` Zhu, Yijun (NSN - CN/Beijing)
2010-03-22  3:29       ` Andi Kleen
2010-03-22  7:45         ` Zhu, Yijun (NSN - CN/Beijing)
2010-03-22  3:56     ` [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.c Yinghai Lu
2010-03-22  4:00       ` David Miller
2010-03-22  4:28         ` Yinghai Lu
2010-03-22  4:33           ` David Miller
2010-03-22  9:28             ` Ingo Molnar
2010-03-22  9:28               ` Ingo Molnar
2010-03-22 11:30               ` Paul Mackerras
2010-03-22 13:05                 ` Ingo Molnar
2010-03-22 13:05                   ` Ingo Molnar
2010-03-22 21:04                   ` Benjamin Herrenschmidt
2010-03-22 21:20                     ` Ingo Molnar
2010-03-22 21:52                       ` Benjamin Herrenschmidt
2010-03-22 22:14                         ` Yinghai Lu
2010-03-22 18:18               ` [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.cy Thomas Gleixner
2010-03-22 19:37                 ` Ingo Molnar
2010-03-22 20:07                   ` Yinghai Lu
2010-03-22 21:08                     ` Benjamin Herrenschmidt
2010-03-22 22:09                     ` Thomas Gleixner
2010-03-22 22:25                       ` Yinghai Lu
2010-03-22 22:53                         ` Thomas Gleixner
2010-03-22 23:41                           ` Yinghai Lu [this message]
2010-03-23  0:45                             ` Thomas Gleixner
2010-03-23  1:04                               ` Yinghai Lu
2010-03-23  1:36                                 ` Thomas Gleixner
2010-03-23  6:01                                   ` Yinghai Lu
2010-03-23  8:02                                     ` Ingo Molnar
2010-03-23  9:02                                       ` Yinghai Lu
2010-03-23  9:48                                         ` Ingo Molnar
2010-03-24  4:29                                           ` Benjamin Herrenschmidt
2010-03-24  4:44                                             ` Benjamin Herrenschmidt
2010-03-24  5:54                                               ` Yinghai Lu
2010-03-24  7:43                                                 ` Benjamin Herrenschmidt
2010-03-24 18:37                                                   ` Yinghai Lu
2010-03-24  9:00                                               ` Ingo Molnar
2010-03-24  9:32                                                 ` Benjamin Herrenschmidt
2010-03-24  4:24                                       ` Benjamin Herrenschmidt
2010-03-24  6:05                                         ` Yinghai Lu
2010-03-22 20:47               ` [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw_memmap.c Benjamin Herrenschmidt
2010-03-22 20:57                 ` Ingo Molnar
2010-03-22 21:54                   ` Benjamin Herrenschmidt
2010-03-23  8:53                     ` Geert Uytterhoeven
2010-03-23 11:16                     ` Ingo Molnar
2010-03-24  4:50                       ` Benjamin Herrenschmidt
2010-03-24  5:47                       ` Kyle Moffett
2010-03-22 21:57                   ` Paul Mackerras
2010-03-22 21:07                 ` Benjamin Herrenschmidt
2010-03-22 21:07                   ` Benjamin Herrenschmidt
2010-03-22 21:01               ` Benjamin Herrenschmidt
2010-03-22  5:12       ` Benjamin Herrenschmidt
2010-03-22  6:09         ` Yinghai Lu
2010-03-22  7:05           ` Eric W. Biederman
2010-03-21  7:13 ` [PATCH 07/20] irq: move some interrupt arch_* functions into struct irq_chip Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 08/20] x86: fix out of order of gsi - full Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 09/20] x86: set nr_irqs_gsi only in probe_nr_irqs_gsi Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 10/20] x86: kill smpboot_hooks.h Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 11/20] x86: use vector_desc instead of vector_irq Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 12/20] genericirq: change ack/mask in irq_chip to take irq_desc instead of irq -- x86 and core Yinghai Lu
2010-03-21  7:13 ` [PATCH 13/20] genericirq: change ack/mask in irq_chip to take irq_desc instead of irq -- other arch Yinghai Lu
2010-03-21  7:13 ` [PATCH 14/20] genericirq: add set_irq_desc_chip/data Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 15/20] x86/iommu/dmar: update iommu/inter_remapping to use desc Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 16/20] x86: use num_processors for possible cpus Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 17/20] x86: make 32bit apic flat to physflat switch like 64bit Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 18/20] x86: remove arch_probe_nr_irqs Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 19/20] x86/pci: ioh new version read all at same time Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-22 16:16   ` Jesse Barnes
2010-03-22 16:16     ` Jesse Barnes
2010-03-22 19:32     ` Yinghai Lu
2010-03-22 19:32       ` Yinghai Lu
2010-03-21  7:13 ` [PATCH 20/20] x86/pci: add mmconf range into e820 for when it is from MSR with amd faml0h Yinghai Lu
2010-03-21  7:13   ` Yinghai Lu
2010-03-22  2:35 ` [PATCH 00/20] x86: early_res and irq_desc Benjamin Herrenschmidt
2010-03-22  3:26   ` Yinghai Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BA80019.5000900@kernel.org \
    --to=yinghai@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).