Hi,
Before bootmem allocator is available, kernel needs allocate memory
pages such as page table and some NUMA structures. On x86_64, this is
done by early_res and find_e820_area. On i386, this is done through
using the memory area after kernel itself which is tracked with
init_pg_tables_end.
Is it better to implement early_res and find_e820_area on i386? Can we
trust E820 table on i386?
Or we add an early_alloc, which allocate memory from the memory area
after kernel itself and check the early_res areas and E820 table too.
BTW: Why not merge e820_32.c and e820_64.c? At least part of them.
Best Regards,
Huang Ying
Huang, Ying wrote:
> Hi,
>
> Before bootmem allocator is available, kernel needs allocate memory
> pages such as page table and some NUMA structures. On x86_64, this is
> done by early_res and find_e820_area. On i386, this is done through
> using the memory area after kernel itself which is tracked with
> init_pg_tables_end.
>
> Is it better to implement early_res and find_e820_area on i386? Can we
> trust E820 table on i386?
>
> Or we add an early_alloc, which allocate memory from the memory area
> after kernel itself and check the early_res areas and E820 table too.
>
> BTW: Why not merge e820_32.c and e820_64.c? At least part of them.
>
What we *should* do, on both i386 and x86-64, is to create a synthetic
e820 table of any non-e820 information, and then yes, we should merge
the code.
In other words, we should have an e820 table which reflects what the
kernel considers true about the memory space.
-hpa
* H. Peter Anvin <[email protected]> wrote:
>> BTW: Why not merge e820_32.c and e820_64.c? At least part of them.
>
> What we *should* do, on both i386 and x86-64, is to create a synthetic
> e820 table of any non-e820 information, and then yes, we should merge
> the code.
>
> In other words, we should have an e820 table which reflects what the
> kernel considers true about the memory space.
i'd strongly support the moving of this from the realm of talk into the
realm of code! :-)
Ingo
On Tuesday 04 March 2008 04:38:03 Huang, Ying wrote:
> Is it better to implement early_res and find_e820_area on i386? Can we
> trust E820 table on i386?
The 64bit code is certainly more flexible and cleaner, but also
much more complicated.. But on the other hand i386 has simpler requirements
so it didn't really need the full power. I didn't think that had changed.
The key change if you wanted to do that would be to change all the unsigned longs to
pfns -- the 64bit code is not all together 32bit clean. Or perhaps better
pfns + page offset since some of the allocations don't need to be page aligned
and would waste memory if they were forced to pfns.
An alternative might be to use the new allocators only for <4GB
on i386 and keep handling >4GB in some other way.
-Andi
* Andi Kleen <[email protected]> wrote:
> On Tuesday 04 March 2008 04:38:03 Huang, Ying wrote:
>
> > Is it better to implement early_res and find_e820_area on i386? Can
> > we trust E820 table on i386?
>
> The 64bit code is certainly more flexible and cleaner, but also much
> more complicated.. [...]
i disagree, the early_res stuff is still quite unclean, and what we want
do do is to get rid of it, not promote it into 32-bit code ... (The
reason we merged the early_res stuff in 2.6.25 was because it was
certainly cleaner than the horrible open-coded reservations that the
64-bit code did before. So now we at least have a more less visible
enumeration of reservations.)
The correct and clean clean solution is what hpa mentioned: to do
reservations in the e820 space. I think hpa has some code for that
already and we should merge that. Peter?
Ingo
On Tuesday 04 March 2008 11:48:53 Ingo Molnar wrote:
>
> * Andi Kleen <[email protected]> wrote:
>
> > On Tuesday 04 March 2008 04:38:03 Huang, Ying wrote:
> >
> > > Is it better to implement early_res and find_e820_area on i386? Can
> > > we trust E820 table on i386?
> >
> > The 64bit code is certainly more flexible and cleaner, but also much
> > more complicated.. [...]
>
> i disagree, the early_res stuff is still quite unclean,
I was mostly refering to the main e820 allocator.
early_res is just an addon table for kernel internal use. While you
could put that into the main e820 table too if you made that one variable
sized I don't think it would make too much difference either way.
It's just a minor tweak of the data structure.
-Andi
Ingo Molnar wrote:
>
> i disagree, the early_res stuff is still quite unclean, and what we want
> do do is to get rid of it, not promote it into 32-bit code ... (The
> reason we merged the early_res stuff in 2.6.25 was because it was
> certainly cleaner than the horrible open-coded reservations that the
> 64-bit code did before. So now we at least have a more less visible
> enumeration of reservations.)
>
> The correct and clean clean solution is what hpa mentioned: to do
> reservations in the e820 space. I think hpa has some code for that
> already and we should merge that. Peter?
>
I do have some code for this stuff, but it's not merge-ready... I'll try
to hammer it into shape.
-hpa