On Tue, Mar 11, 2014 at 9:42 AM, H. Peter Anvin <h...@linux.intel.com> wrote: > On 03/11/2014 09:30 AM, Linus Torvalds wrote: >> >> No, the trivial solution is to stop adding crap to it. >> >> And no, "just reserve a little more space for it" is neither trivial >> nor a good idea. The fixed VDSO address is very much at the top of the >> address space, so you can't allocate more space for it unless you do >> one of >> >> (a) make it non-contiguous >> (b) get rid of the hole that is the very last page >> (c) mess with the vsyscall pages and make it contiguous "backwards" >> >> all of which sound like *horrible* ideas. Certainly not "trivial solution". >> >> No, the trivial solution is to not mess with that legacy page at all. >> >> Why is *that* trivial solution not on the table? Why the heck are >> people hell-bent on changing this stupid legacy page around? >> >> I find this whole thread very annoying. We shouldn't care about >> x86-32, and certainly not from a performance angle - we should >> consider it a "it's done, don't touch it" issue. >> > > Andy actually did the research, and found that even the legacy VDSO > doesn't have to live at any one particular address, it just has to live > at the address it is linked at. So we can move it just fine, but we > have to change the link address to match. > > That gives us a lot more maneuvering room than saying it has to be at > one specific address. >
We could even just relocate the damn thing wherever it ends up. That will waste one page of memory per process, though. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
