Messages in this thread | | | Date | Sun, 01 Mar 2009 17:02:41 -0800 | From | Yinghai Lu <> | Subject | Re: brk patches.. |
| |
Jeremy Fitzhardinge wrote: > Yinghai Lu wrote: >>> But its no different from what i386 does now to allocate its initial >>> pagetables. How does this not break now? >>> >>> >> >> it will try to use initial page table af first, and it is not big >> enough, it will according to e820 and other reserved_early areas to >> find good positions. >> > > head_32.S has no such logic. It just starts building the kernel > mappings directly after _end, starting at pg0, and uses as much space as > it needs. For a !PSE CPU with a large kernel, that can be quite a lot > of space. Only later, when its creating the linear memory mappings, > does it search around in the e820 tables (which it now has access to) > for space.
yes, we should have some way to only make initial_pgtable only cover to _end and put that initial_pagbe before _end.
> > The whole point of the brk segment was to have a way of allocating some > memory very early, before e820 is even available. If you really think > this is dangerous, then we can easily extend the bss in the linker > script to include the brk memory, and release any leftover when we do > the normal bootmem freeup. That would also give us a well-defined upper > limit on how much brk memory can be allocated; its a bit undefined at > the moment, as it depends on how much slop there is after the kernel > mapping.
hope later boot loader could check vmlinux size in bzImage (according uncompressed size) and find good position in RAM for bzImage.
we should find good position for brk with find_e820_area().
YH
| |