> > Right so I could move the kernel to > > #define __PAGE_OFFSET _AC(0xffff810000000000, UL) > #define __START_KERNEL_map_AC(0xfffffff800000000, UL)
That is -31GB unless I'm miscounting. But it needs to be >= -2GB (31bits) Right now it is at -2GB + 2MB, because it is loaded at physical +2MB so it's convenient to identity map there. In theory you could avoid that with some effort, but that would only buy you 2MB and would also break some early code and earlyprintk I believe. > > You could in theory move the modules, but then you would need to implement > > a full PIC dynamic linker for them first and also increase runtime overhead > > for them because they would need to use a GOT/PLT. > > Why is it not possible to move the kernel lower while keeping bit 31 1? The kernel model relies on 32bit sign extension. This means bits [31;63] have to be all 1 > > I suspect all of this would cause far more overhead all over the kernel > > than > > you could ever save with the per cpu data in your fast paths. > > Moving the kernel down a bit seems to be trivial without any of the weird > solutions. Another one I came up in the previous mail would be to do the linker reference variable allocation in [0;2GB] positive space; but do all real references only %gs relative. And keep the real data copy on some other address. That would be a similar trick to the old style x86-64 vsyscalls. It gets fairly messy in the linker map file though. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/