Prev: HID:HID-NTRIG update ntrig_event function
Next: power_meter: acpi_device_class "power_meter_resource" too long
From: Yinghai Lu on 24 Mar 2010 02:10
On 03/23/2010 09:24 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2010-03-23 at 09:02 +0100, Ingo Molnar wrote:
>>> -u64 find_fw_memmap_area(u64 start, u64 end, u64 size, u64 align);
>>> +u64 find_lmb_area(u64 start, u64 end, u64 size, u64 align);
>>> +u64 find_lmb_area_size(u64 start, u64 *sizep, u64 align);
>>> +u64 find_lmb_area_node(int nid, u64 start, u64 end, u64 size, u64
>> align);
>>> +void lmb_register_active_regions(int nid, unsigned long start_pfn,
>>> + unsigned long last_pfn);
>>> +u64 lmb_hole_size(u64 start, u64 end);
>>> u64 get_max_mapped(void);
>>> #include <linux/range.h>
>>> int get_free_all_memory_range(struct range **rangep, int nodeid);
>>
>> those new lmb_*() APIs should go into lmb.h.
>
> And while at it properly documented :-) I wouldn't mind also a
> reasonably clear explanation in the changeset comment as to why
> they are necessary for x86.

new early_res.c will have
find_lmb_area
reserve_early
free_early
also have get_free_all_memory_range to support bootmem replacement.

find_lmb_area: will take goal/limit, so we can find free region with more control.

when we try to check if there is enough slots for new reserve entry.
we need to make sure the new array will not overlap with range below to
entry that going to be reserved.
so we need to goal for find.
otherwise you have to keep trying with lmb_alloc until get one for new array
that will not overlap with new entry.


>
> To be honest, that's my #1 grief so far with this entire patch set,
> it Yinghai apparent inability to write anything ressembling remotely
> like an explanation. All we get is key words, bullet points and half
> sentences, and I admit have a very very hard time extracting a meaning
> out of anything he's been writing so far.

will spend more time to write more sentences...

thought you guys like to read code instead.

Thanks for you patience.

Yinghai Lu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 24 Mar 2010 05:10

* Benjamin Herrenschmidt <benh(a)kernel.crashing.org> wrote:

>
> > I though one possibility would be to have LMB regions become more lists
> > than arrays, so that the static storage only needs to cover as much as
> > is needed during really early boot (and we could probably still move the
> > BSS top point on some archs to dynamically make more ... actually we
> > could be smart arses and use LMB to allocate more LMB list heads if we
> > are reaching the table limit :-)
>
> Actually what about that:
>
> LMB entries are linked-listed. The array is just storage for those entry
> "heads".
>
> The initial static array only needs to be big enough for very very early
> platform specific kernel bits and pieces, so it could even be sized by a
> Kconfig option. Or it could just use a klimit moving trick to pick up a
> page right after the BSS but that may need to be arch specific.
>
> lmb_init() queues all the entries from the initial array in a freelist
>
> lmb_alloc() and lmb_reserve() just pop entries from that freelist to
> populate the two main linked lists (memory and reserved).
>
> When something tries to dequeue up the last freelist entry, then under
> the hood, LMB uses it instead to allocate a new block of LMB entries
> that gets added to the freelist.
>
> We never free blocks of LMB entries.
>
> That way, we can fine tine the static array to be as small as we can
> realistically make it be, and we have no boundary limitations on the
> amount of entries in either the memory list or the reserved list.
>
> I'm a bit too flat out right now to write code, but if there's no objection,
> I might give that a go either later this week or next week, see if I can
> replace bootmem on powerpc.

That would be fantastic! PowerPC and x86 both doing it would give it enough of
a critical mass to make the removal of bootmem realistic.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 24 Mar 2010 14:40
On 03/24/2010 12:43 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2010-03-23 at 22:54 -0700, Yinghai Lu wrote:
>> if the array can be doubled and have old one copied to new one.
>> then we don't change lmb.c too much.
>>
>> new early_res.c exend lmb. and another half already works with x86 to
>> replace bootmem.
>>
>> will check if i can produce one patch to make powerpc to reuse
>> early_res/nobootmem
>
> While at it, can you rename early_res to something that doesn't
> suck ? :-)
>
ok,

please check following renaming is ok to you.

the api from linux/early_res.h

#ifndef _LINUX_EARLY_RES_H
#define _LINUX_EARLY_RES_H
#ifdef __KERNEL__

extern void reserve_early(u64 start, u64 end, char *name);
extern void free_early(u64 start, u64 end);
void lmb_reserved_to_bootmem(u64 start, u64 end);

u64 find_early_area(u64 ei_start, u64 ei_last, u64 start, u64 end,
u64 size, u64 align);

void add_lmb_memory(u64 start, u64 end);

u64 find_lmb_area(u64 start, u64 end, u64 size, u64 align);
u64 find_lmb_area_size(u64 start, u64 *sizep, u64 align);
u64 find_lmb_area_node(int nid, u64 start, u64 end, u64 size, u64 align);
void lmb_register_active_regions(int nid, unsigned long start_pfn,
unsigned long last_pfn);
u64 lmb_hole_size(u64 start, u64 end);
u64 get_max_mapped(void);
struct range;
int get_free_all_memory_range(struct range **rangep, int nodeid);

#endif /* __KERNEL__ */

#endif /* _LINUX_EARLY_RES_H */

====>

extern void reserve_lmb(u64 start, u64 end, char *name);
extern void free_lmb(u64 start, u64 end);
void lmb_reserved_to_bootmem(u64 start, u64 end);

u64 __find_lmb_area(u64 ei_start, u64 ei_last, u64 start, u64 end,
u64 size, u64 align);

void add_lmb_memory(u64 start, u64 end);

u64 find_lmb_area(u64 start, u64 end, u64 size, u64 align);
u64 find_lmb_area_size(u64 start, u64 *sizep, u64 align);
u64 find_lmb_area_node(int nid, u64 start, u64 end, u64 size, u64 align);
void lmb_register_active_regions(int nid, unsigned long start_pfn,
unsigned long last_pfn);
u64 lmb_hole_size(u64 start, u64 end);
u64 get_max_mapped(void);
struct range;
int get_free_all_memory_range(struct range **rangep, int nodeid);

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4
Prev: HID:HID-NTRIG update ntrig_event function
Next: power_meter: acpi_device_class "power_meter_resource" too long