On Wed, Jul 21, 2021 at 01:25:36PM +0300, Kirill A. Shutemov wrote: > On Wed, Jul 21, 2021 at 11:25:25AM +0200, Joerg Roedel wrote: > I modify E820 as needed: > > e820__range_update(start, end, E820_TYPE_UNACCEPTED, E820_TYPE_RAM); > > I also ask memblock for bottom-up allocation as it helps with using > per-accepted pages first and reduces fragmentation: > > memblock_set_bottom_up(true); This happens already in the decompressed kernel image. The decompressor also needs to be able to validate memory and pass the information about it on. > I tried to postpone thinking about decompresser as long as possible :P > > I guess we need pass down information about memory accepted in > decompresser to the main kernel so it can record in E820. I think it will > a single range. This means modifying the E820 array in boot_params in the decompressor, handling overlaps, splitting entries and all that. > Yes, the bitmap is small, but it going to be rather hot structure. It has > to be consulted on every page allocation, right? > > How to do plan to make bitmap scalable? What the locking rules around it? It is expected that the bitmap becomes read-mostly over time, so the cache-lines can be shared. The access should be possible using only atomic bit manipulation instructions when validation happens in the memory allocators, because no one is trying to modify the same bits concurrently. Regards, Joerg
