On Mon, 2019-06-10 at 13:43 -0700, Dave Hansen wrote: > 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? Yes.
