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
next prev parent 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).