On 6/10/19 1:27 PM, Yu-cheng Yu wrote: >>> If the loader cannot allocate a big bitmap to cover all 5-level >>> address space (the bitmap will be large), it can put all legacy lib's >>> at lower address. We cannot do these easily in the kernel. >> This is actually an argument to do it in the kernel. The kernel can >> always allocate the virtual space however it wants, no matter how large. >> If we hide the bitmap behind a kernel API then we can put it at high >> 5-level user addresses because we also don't have to worry about the >> high bits confusing userspace. > We actually tried this. The kernel needs to reserve the bitmap space in the > beginning for every CET-enabled app, regardless of actual needs. I don't think this is a problem. In fact, I think reserving the space is actually the only sane behavior. If you don't reserve it, you fundamentally limit where future legacy instructions can go. One idea is that we always size the bitmap for the 48-bit addressing systems. Legacy code probably doesn't _need_ to go in the new address space, and if we do this we don't have to worry about the gigantic 57-bit address space bitmap. > On each memory request, the kernel then must consider a percentage of > allocated space in its calculation, and on systems with less memory > this quickly becomes a problem. I'm not sure what you're referring to here? Are you referring to our overcommit limits?
